EP1133849A1 - Verfahren und vorrichtung zum erzeugen eines verschlüsselten nutzdatenstroms und verfahren und vorrichtung zum entschlüsseln eines verschlüsselten nutzdatenstroms - Google Patents

Verfahren und vorrichtung zum erzeugen eines verschlüsselten nutzdatenstroms und verfahren und vorrichtung zum entschlüsseln eines verschlüsselten nutzdatenstroms

Info

Publication number
EP1133849A1
EP1133849A1 EP99965472A EP99965472A EP1133849A1 EP 1133849 A1 EP1133849 A1 EP 1133849A1 EP 99965472 A EP99965472 A EP 99965472A EP 99965472 A EP99965472 A EP 99965472A EP 1133849 A1 EP1133849 A1 EP 1133849A1
Authority
EP
European Patent Office
Prior art keywords
user data
key
encrypted
header
data stream
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.)
Granted
Application number
EP99965472A
Other languages
English (en)
French (fr)
Other versions
EP1133849B1 (de
Inventor
Niels Rump
Jürgen Koller
Karlheinz Brandenburg
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.)
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Original Assignee
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
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 Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV filed Critical Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Publication of EP1133849A1 publication Critical patent/EP1133849A1/de
Application granted granted Critical
Publication of EP1133849B1 publication Critical patent/EP1133849B1/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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2347—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving video stream encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video stream decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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
    • H04N21/8355—Generation of protective data, e.g. certificates involving usage data, e.g. number of copies or viewings allowed

Definitions

  • Method and device for generating an encrypted user data stream and method and device for decrypting an encrypted user data stream
  • the present invention relates to the encryption and decryption of user data and, in particular, to an encryption concept in which the user data are encrypted using a specific key, this key in turn being encrypted in order to implement customer-selective transmission of user data.
  • telecommunications networks With the appearance of telecommunications networks and in particular due to the wide spread of multimedia data-capable personal computers and, more recently, so-called solid-state players, there has been a need to digital multimedia data such.
  • the telecommunications networks can, for example, analog phone lines, digital phone lines such.
  • commercial providers of multimedia products there is a need to sell or lend multimedia data, whereby it should be possible for a customer to be able to select a specific product from a specific catalog at any time, which of course is only available from the customer who has paid for it , may be used.
  • the present invention is to provide methods and devices which allow individual, customer-selective and secure encryption and Enable decryption of multimedia data.
  • the methods and devices of the present invention allow the customer maximum freedom of choice, ie the customer only has to pay for the products which he actually does wants to use.
  • DE 196 25 635 C1 describes methods and devices for encrypting or decrypting multimedia data, the multimedia data being in the form of an encrypted multimedia file which has a determination data block and a user data block. Parts of the determination data block and at least parts of the user data block are encrypted with different keys, symmetrical encryption methods being used in particular.
  • symmetrical encryption methods have the advantage that they work relatively quickly.
  • the user who wants to decrypt the file needs the same key as the provider or supplier, e.g. B. DeutscheInstitut, who encrypted the multimedia data in order to sell it to the customer.
  • the provider and the user i. H. the customer
  • a table with many possible symmetric encryption algorithms such as B. DES or Blowfish
  • a table for possible keys such that the provider creates an entry in the destination data block of the multimedia data that the user uses to access his key table in order to select the correct key for decryption.
  • the object of the present invention is to create an efficient and secure concept for encrypting and decrypting multimedia data.
  • This object is achieved by a method for generating an encrypted multimedia data stream according to claim 1, by a method for decrypting an encrypted multimedia data stream according to claim 17, by a device for generating an encrypted multimedia data stream according to claim 27 and by a device for decrypting an encrypted multimedia data stream according to claim 28 solved.
  • the present invention is based on the knowledge that a so-called hybrid encryption method must be used for secure and efficient encryption, the faster z.
  • the encrypted user data stream which on the one hand could be a user file or can be a continuous data stream, is to be secured against unauthorized manipulation.
  • the asymmetrical encryption method for encrypting the user data key itself includes the user data stream itself.
  • a hash sum of part of the multimedia data stream is preferably generated.
  • this part could only be the start block of the multimedia data stream, on the other hand it could also comprise parts of the encrypted or unencrypted multimedia data itself.
  • An output value in the header which is transmitted to the customer together with the at least partially encrypted multimedia data in the form of the multimedia data stream, represents, so to speak, an encrypted version of the multimedia data key, in order to correctly decrypt this output value again in order to encrypt the multimedia data key receive, in addition to the key for the asymmetric encryption method, also individual duel data, such as B. license data, which relate to the way in which a user may use the encrypted multimedia data at all, and can also be parts of the multimedia data itself. Therefore, if a user manipulates the header, for example by changing the expiry date of his license to use a specific piece of multimedia, he can no longer determine the correct key for decrypting the encrypted multimedia data, since it is no longer possible to correctly decrypt the output value .
  • a major advantage of the method is that as soon as someone changes the header, the hash sum changes over the header. As a result, it is no longer possible to correctly determine the key for decrypting the multimedia data. Any change to the header will automatically destroy the multimedia data itself.
  • This "implicit" protection of the header does not include encryption of the header, which is why it does not have to be decrypted, which in turn can be used to save resources in the playback devices.
  • an encryption of the header would be easily possible if there is a desire.
  • FIG. 1 shows a multimedia data stream which according to the present gene invention can be generated
  • FIG. 4 shows a flow chart for the method for generating an encrypted multimedia data stream according to the present invention, which is preferably carried out by a distributor, i. H. a supplier of multimedia data; and
  • FIG. 5 shows a method for decrypting an encrypted multimedia data stream according to the present invention, which is preferably carried out for a customer or user of the multimedia data.
  • Fig. 1 shows an encrypted multimedia data stream 10, the header or header 12 and a user data block 14, i. H. has a block with encrypted multimedia data.
  • the payload block 14 includes encrypted sections 16 and unencrypted sections 18 between the encrypted sections 16.
  • a multimedia data stream that can be generated in accordance with the present invention includes another unencrypted section 20 that follows the header 12 and is located in front of an encrypted section 16 is.
  • the multimedia data to be encrypted is encoded in some way, e.g. B. according to an MPEG standard, such as. B. MPEG-2 AAC, MPEG-4 Audio or MPEG Layer-3. It is therefore sufficient to encrypt certain sections of the multimedia data to be encrypted. This leads to a significantly reduced processing effort both for the provider who encrypts the data and for the Customer who has to decrypt the data again.
  • MPEG-2 AAC MPEG-2 AAC
  • MPEG-4 Audio MPEG Layer-3
  • header 12 is arranged at the beginning of the encrypted multimedia data stream, this arrangement of the header and user data block is not intended to relate to the transmission of the encrypted multimedia data stream.
  • header is only intended to express that a decryption device that wants to decrypt the encrypted multimedia data stream first needs at least parts of the header before the multimedia data itself can be decrypted.
  • the header could also be located somewhere within the user data block or could be received after certain parts of the user data block, for example if a packet-oriented transmission of the multimedia data stream is being considered, in which different packets, one of which can contain the header, and another part of the useful data block can be transmitted via different physical transmission paths, such that the order of reception does not have to correspond to the order of transmission at all.
  • a decryption device in this case must be able to store and reorder the received packets such that information is extracted from the header to begin decryption.
  • the encrypted multimedia data stream could also be in the form of a file or else in the form of an actual data stream if, for example, a live transmission of a multimedia event is being considered.
  • the length of an encrypted section 16 is represented by a value set 22, while the distance in the encrypted multimedia data stream from the beginning of an encrypted section 16 to the beginning of the next encrypted section 16 is designated with step 24.
  • the length of the further encrypted section 20 is indicated by a value of first step 26.
  • FIG. 2 shows a more detailed illustration of the encrypted multimedia data stream 10, which consists of the header 12 and the user data block 14.
  • the starting block 12 is divided into a number of sub-blocks, which are explained in detail with reference in particular to FIG. 3. It should be pointed out that the number and function of the sub-blocks can be expanded as desired. In FIG. 2, individual sub-blocks of the starting block 12 are therefore only shown as examples. The same comprises, as shown in FIG. 2, a so-called crypt block 29, which generally speaking contains information relevant for the encryption of the multimedia data.
  • the header 12 further includes a so-called license block 30, which has data relating to the way in which a user can or may use the encrypted multimedia data stream.
  • the header 12 also includes a user data info block 32, which can include information regarding the user data block 14 and general information about the header 12 itself. Furthermore, the header 12 can have an age header block 34, which enables a so-called recursive header structure. This block enables the user, who in addition to a decryption device also has an encryption device, to generate an encrypted multimedia data stream for reformate other players in its possession without losing or modifying the original header information provided by the distributor. Depending on the area of application, further sub-blocks such as B.
  • ISO / IEC 14496-1, MPEG-4, Systems, 1998 which includes copyright information, are added to the header 12.
  • an internal block structure can be assigned to each block, which first requires a block identifier, which then comprises the length of the sub-block, and which then finally lists the block payload itself.
  • FIG. 3 gives an overview of the block useful data of the individual subblocks shown in FIG. 2.
  • the crypt block 28 contains an entry for a multimedia data encryption algorithm 40 that identifies the symmetric encryption algorithm used in a preferred embodiment that was used in encrypting the multimedia data. Entry 40 should be an index to a table such that a decryption device, after reading entry 40, is able to select the same encryption algorithm from a variety of encryption algorithms that the encryption device used.
  • the crypt block 28 further comprises the entry first step 26, the entry step 24 and the entry quantity 22, which have already been shown in connection with FIG. 1. These entries in the header put a decryption device in the Able to subdivide an encrypted multimedia data stream accordingly in order to be able to carry out a correct decryption.
  • the crypt block 28 also contains an entry for the distributor or provider 42, which is a code for the distributor that generated the encrypted multimedia data stream.
  • An entry user 44 identifies the user who has received the encrypted multimedia data stream in some way from the distributor identified by the entry 42.
  • One possible use of these identifiers is to - carry out the user identification device-specifically.
  • the entry user would then include the serial number of a PC, a laptop, a car hi-fi device, a home stereo system, etc., which only allows playback on the special device.
  • a special identifier such as B. a logical link of the hard disk size with the processor number etc. in the example of a PC.
  • An entry 46 contains an output value, which will be discussed in detail later. Generally speaking, this output value represents an encrypted version of the multimedia data key which, in conjunction with the multimedia data encryption algorithm identified by the entry 40, is required in order to correctly decrypt the encrypted multimedia data (sections 16 of FIG. 1) present in the user data block 14 .
  • the two entries output value length 48 and output value mask 50 are also provided.
  • the entry output value length 48 indicates the length of the output value 46. In order to obtain a flexible header format, however, there are more bytes in the header format for the output value. see as an output value currently actually has.
  • the output value mask 50 therefore specifies how a shorter output value is to a certain extent distributed over a longer output value space.
  • the output value mask could be designed such that the first half of the output value mask is set is while the second half is covered. Then the output value would simply be entered in the space provided by the syntax for the header and occupy the first half, while the other half is ignored due to the output value mask 50.
  • the license block 30 of the starting block 12 is discussed below.
  • the same includes an entry bit mask 52.
  • This entry can have certain special information for playing or for the general way of using the encrypted multimedia data.
  • a decryption device could hereby be informed whether or not the user data can be played locally.
  • it could be signaled here whether the challenge-response method for encryption has been used, which is described in the aforementioned German patent DE 196 25 635 C1 and enables efficient database access.
  • An expiry date entry 54 indicates the time at which the permission to decrypt the encrypted multimedia data stream expires.
  • a decryption device will check the entry expiry date 54 and compare it with a built-in time measuring device in order not to decrypt the encrypted multimedia data stream in the event that the expiry date has already passed.
  • This allows a provider to provide encrypted multimedia data for a limited time, which enables the advantage of much more flexible handling and pricing.
  • This flexibility is further enhanced by an entry start date 56 supported, in which it is specified when an encrypted multimedia file may be decrypted.
  • An encryption device will compare the entry start date with its built-in clock in order to decrypt the encrypted multimedia data only when the current time is later than the start date 56.
  • An entry allowed number of plays 58 indicates how often the encrypted multimedia data stream is decrypted, i. H. can be played. This further increases the flexibility of the provider in such a way that it only allows a certain number of plays, for example against a certain sum, which is smaller than a sum that would arise for the unrestricted use of the encrypted multimedia data stream.
  • the license block 30 further comprises an entry actual number of plays 60, which could be incremented by one after each decryption of the encrypted multimedia data stream, for example.
  • a decryption device will therefore always check whether the entry actual number of plays is smaller than the entry permitted number of plays. If this is the case, the multimedia data is decrypted. If this is not the case, decryption is no longer carried out.
  • entries 58 and 60 Analogous to entries 58 and 60, the entries permitted number of copies 62 and actual number of copies 64 have been implemented.
  • the two entries 62 and 64 ensure that a user of the multimedia data copies the same only as often as the provider allows him or as often as he paid for when buying the multimedia data.
  • the entries 58 to 64 ensure effective copyright protection and can be used to select between private and commercial users can be achieved, for example by setting the entries permitted number of plays 58 and permitted number of copies 62 to a small value.
  • the licensing could e.g. B. be designed so that a certain number of copies (entry 62) of the original is allowed, while no copies of a copy are allowed. In contrast to the header of the original, the entry block of a copy would then have a zero as the entry allowed number of copies, such that this copy is no longer copied by a correct encryption / decryption device.
  • the header 12 also contains a useful data information block 32, which here only has two block useful data entries 66 and 68, the entry 66 having a hash sum over the contains the entire header, while entry 68 identifies the type of hash algorithm that has been used to form the hash sum over the entire header.
  • the header 12 finally includes the age header block 34, which in addition to the synchronization information, which is not shown in FIG. 3, has the entry age header 70.
  • the old header can be saved by the provider in order not to lose any essential information that the provider in has entered the header.
  • This could include, for example, copyright information (IP information block), previous user information and distributor information, which enable a multimedia file that has been decrypted / encrypted several times by different devices, for example, to be traced back to the original provider, while preserving copyright information. This makes it possible to check at any time whether an encrypted multimedia file has been acquired legally or illegally.
  • the encryption method according to the invention is carried out at the distributor.
  • the distributor preferably carries out a hybrid encryption process, i. H. a symmetrical encryption method for encrypting the multimedia data and an asymmetrical encryption method for encrypting the multimedia data key.
  • a customer or user who wants to acquire multimedia data from a distributor first contacts the distributor and could, for example, provide him with his credit card number, from which the distributor debits any amounts due.
  • the distributor then receives a table of symmetrical encryption methods from the distributor.
  • the distributor and customer also exchange their public keys. If the user now orders a certain multimedia work from the distributor, the distributor carries out customer-selective encryption for this customer.
  • the steps for generating the encrypted multimedia data stream could be as follows.
  • the distributor first creates the header 12 for the multimedia file as far as possible (100).
  • the output value is not yet available at this point in time. Therefore, in step 100, in which header 12 is created as much as possible, the entry for the output value is left blank.
  • all other entries in the crypt block and all other entries in the license block already exist here.
  • the entry age header 70 will also very likely remain free when the multimedia file is encrypted by the distributor for the first time. However, if the distributor acquired the encrypted multimedia file from another distributor, entry 70 could already be filled.
  • the distributor determines a multimedia data key K which, together with the multimedia data encryption algorithm, which is identified by the entry 40 (FIG. 3), permits encryption of the multimedia data, which is carried out in a step 104.
  • a hash sum is formed over the header, with certain parts having a predefined value (step 106).
  • the detailed illustration of the starting block in FIG. 3 contains a column 107 on the right-hand edge, which is intended to illustrate which parts or entries in the starting block 12 receive a predefined value when forming a hash sum in step 106 (FIG. 4).
  • the entry output value 46, the entry actual number of plays 60, the entry actual number of copies 64 and the entry hash sum via the start block 66 and possibly the entry age-start block 70, as indicated by the dotted cross for the entry, receive a predefined value 70 is shown.
  • Certain parts of the header must be assigned a predefined value when the hash sum in the step 106 is formed since these are not yet fixed (output value 46) or are changed by a decryption device (entries 60 and 64).
  • the entry 66 ie the hash sum over the start block, has also not yet been determined since the output value 46 is of course also included in it.
  • the entries distributor 42, user 44 and the entries in the license block 30 are, however, included when the hash sum is formed in step 106 (FIG. 4), as a result of which personalization or protection of the license block entries is already achieved since the hash sum obtained in step 106 is linked to the multimedia data key to obtain a base value (step 108).
  • step 108 The base value obtained in step 108 is then asymmetrically encrypted using the customer's public key ( ⁇ ) (step 110).
  • step 110 the starting block is finally completed (step 112) in such a way that the output value 46 is entered in the starting block already created in step 100.
  • step 108 cannot be carried out until the hash sum has been determined.
  • step 110 can only be carried out when the base value is present.
  • a symmetrical encryption method was used for the multimedia data key in step 104, since here relatively large amounts of data may have to be encrypted or decrypted.
  • symmetrical encryption methods work faster than asymmetrical encryption methods, such as are used in step 110 for encrypting the multimedia data key.
  • the multimedia data key K is generated by means of a random number generator such that the base value which is generated in step 108 takes on a different form for the same customer each time, so as to make it difficult for an attacker to the cryptographic system to make as possible.
  • the link operation to link the hash sum with the multimedia data key K should, as will be explained with reference to FIG. 5, be a self-inverse link.
  • Such a self-inverse link would be the XOR (exclusive-or) link.
  • Self inverse means that applying this link twice leads to a result that is equal to the initial value.
  • the linking function from FIG. 5 is the inverse function of that from FIG. 4.
  • the linking function must therefore only be reversible, i. H. an inverse function must exist for the same.
  • an asymmetrical encryption method is carried out according to the present invention.
  • One key is called the private key P, while the other key is called the public key ⁇ .
  • asymmetrical encryption methods have the property that data to be encrypted which has been encrypted using the private key can be decrypted with the public key. Similarly, data to be encrypted that has been encrypted with the public key can be decrypted again with the private key. From this it can be seen that the private and public keys are in principle interchangeable.
  • the header is involved in the encryption of the multimedia data key via steps 106 and 108.
  • parts of the user data block could also be included, which would render the entire multimedia data stream unusable due to unauthorized manipulation of the user data, since it would then no longer be possible to calculate the multimedia data key in the decryption device.
  • step 106 a hash sum is formed over the header
  • any processing of a portion of the multimedia stream could be used to derive information identifying the portion of the multimedia stream.
  • the more complex the hash algorithm that is used here the more secure the encrypted multimedia data stream becomes against attackers who want to crack it, for example to modify the license information or the distributor or user information in their (unauthorized) sense.
  • FIG. 5 shows a flow diagram of the decryption process that may be performed by a customer.
  • the customer first reads the output value from the header of the encrypted multimedia data stream. He then decrypts this output value using the corresponding asymmetric decryption (step 122).
  • the decryption device at the customer then forms a hash sum over the intercept block, wherein the specific parts that had a predefined value when encrypted also receive the same predefined value in a step 124.
  • the hash sum is then linked to the decrypted output value (step 122), which results in the multimedia data key (step 126).
  • the encrypted multimedia data is decrypted using the multimedia data key obtained in step 126.
  • the decryption method essentially represents the reverse of the encryption method which has been described with reference to the flow diagram of FIG. 4.
  • the hash sum could first be formed via the header (step 124), after which the output value is decrypted using the public key (step 122).
  • the reading of the output value from the starting block (step 120) can also be carried out, for example, only after step 124, but definitely before step 126.
  • Step 128 is also only possible after step 126 has been carried out, since this results in the multimedia data key.
  • the decryption method shown in FIG. 5 clearly uses step 124 to express once again what happens when a customer has modified header 12, which is usually unencrypted and is easily accessible for attacks.
  • changing the license information for example the start and end dates, would inevitably lead to the fact that the hash sum over the start block, which is formed in step 124, has a different value than the hash sum, which was generated in step 106 (FIG. 4) has been formed during encryption.
  • the new combination of the hash sum in step 126 (FIG. 5) will therefore no longer lead to the correct multimedia data key, since the two hash sums, ie the The hash sum during encryption and the hash sum during decryption are different from one another.

Description

Verfahren und Vorrichtung zum Erzeugen eines verschlüsselten Nutzdatenstroms und Verfahren und Vorrichtung zum Entschlüsseln eines verschlüsselten Nutzdatenstroms
Beschreibung
Die vorliegende Erfindung bezieht sich auf die Verschlüsselung und Entschlüsselung von Nutzdaten und insbesondere auf ein Verschlüsselungskonzept, bei dem die Nutzdaten mittels eines bestimmten Schlüssels verschlüsselt sind, wobei dieser Schlüssel wiederum selbst verschlüsselt ist, um eine kundenselektive Übertragen von Nutzdaten zu verwirklichen.
Mit dem Auftreten von Telekommunikationsnetzen und insbesondere aufgrund der großen Verbreitung von Multimediadaten-fähigen Personalcomputern und in letzter Zeit auch von sogenannten Solid-State-Playern, entstand ein Bedarf, digitale Multimediadaten, wie z. B. digitale Audiodaten und/oder digitale Videodaten, kommerziell zu vertreiben. Die Telekommunikationsnetze können beispielsweise analoge Telephonleitungen, digitale Telephonleitungen, wie z. B. ISDN, oder auch das Internet sein. Unter kommerziellen Anbietern von Multimediaprodukten besteht der Bedarf, Multimediadaten zu verkaufen oder auszuleihen, wobei es einem Kunden möglich sein sollte, aus einem bestimmten Katalog zu jeder Zeit individuell ein bestimmtes Produkt auswählen zu können, das dann selbstverständlich nur von dem Kunden, der dafür bezahlt hat, benutzt werden darf.
Im Gegensatz zu bekannten verschlüsselten Fernsehprogrammen, wie z. B. von dem Fernsehkanal Premiere, bei dem die ausgesendeten Daten für alle Benutzer, die gegen eine bestimmte Gebühr eine geeignete Entschlüsselungsvorrichtung erworben haben, gleich verschlüsselt sind, soll die vorliegende Erfindung Verfahren und Vorrichtungen schaffen, die eine individuelle, kundenselektive und sichere Verschlüsselung und Entschlüsselung von Multimediadaten ermöglichen. Im Gegensatz zu den genannten Fernsehkanälen, die ein festes Programm vorgeben, für das sich der Benutzer komplett entscheiden—muß, ermöglichen die Verfahren und Vorrichtungen der vorliegenden Erfindung eine maximale Wahlfreiheit des Kunden, d. h. derselbe muß nur für die Produkte bezahlen, die er tatsächlich auch benutzen will.
Die DE 196 25 635 Cl beschreibt Verfahren und Vorrichtungen zum Ver- bzw. Entschlüsseln von Multimediadaten, wobei die Multimediadaten in Form einer verschlüsselten Multimediadatei vorliegen, die einen Bestimmungsdatenblock und einen Nutzdatenblock aufweist. Teile des Bestimmungsdatenblocks sowie zumindest Teile des Nutzdatenblocks werden mit unterschiedlichen Schlüsseln verschlüsselt, wobei insbesondere symmetrische Verschlüsselungsverfahren eingesetzt werden.
Symmetrische Verschlüsselungsverfahren haben einerseits den Vorteil, daß sie relativ schnell arbeiten, andererseits benötigt der Benutzer, der die Datei entschlüsseln will, den gleichen Schlüssel wie der Provider oder Lieferant, z. B. die Deutsche Telekom, der die Multimediadaten verschlüsselt hat, um sie an den Kunden zu verkaufen. Somit haben sowohl der Provider als auch der Benutzer, d. h. der Kunde, einerseits eine Tabelle mit vielen möglichen symmetrischen Verschlüsselungsalgorithmen, wie z. B. DES oder Blowfish, und andererseits eine Tabelle für mögliche Schlüssel, derart, daß vom Provider ein Eintrag in dem Bestimmungsdatenblock der Multimediadaten erzeugt wird, den der Benutzer verwendet, um damit auf seine Schlüsseltabelle zuzugreifen, um den korrekten Schlüssel zum Entschlüsseln auszuwählen.
Aufgrund der stark zunehmenden Verbreitung des MP3-Standards sind auf dem Markt sogenannten Solid-State-Player erschienen, die zum Entschlüsseln und Abspielen von Multimediadaten eingesetzt werden sollen. Diese Geräte sollen sehr preisgünstig sein und dürfen daher lediglich eine begrenzte Menge an Speicherplatz und Rechenleistung haben. Im Gegensatz zu Personalcomputern, bei denen die vorhandenen Ressourcen die für die Entschlüsselung von Multimediadaten benötigten Ressourcen bei weitem übersteigen, müssen Solid-State-Player oder^ Stereoanlagen oder Auto-HiFi-Geräte, damit sie sich auf dem hart umkämpften Markt durchsetzen können, preiswert sein. Dazu ist es erforderlich, diese Geräte beim Entschlüsseln und Abspielen der entschlüsselten Multimediadaten soweit als möglich bezüglich Rechenleistung und Speicherplatz zu entlasten. Andererseits besteht nach wie vor die Anforderung, daß die verwendeten Verschlüsselungstechniken ausreichend sicher sind, um für einen Kunden vertrauenswürdig zu sein, und um einen Mißbrauch auch verschlüsselter Multimediadaten zu vermeiden. Weiterhin gilt es, wirksam Urheberrechtsverletzungen zu begegnen, insbesondere, wenn Multimediadaten ohne Autorisierung durch den Urheber bzw. eine Verwertungsgesellschaft abgespielt werden, oder auch ohne Autorisierung verändert werden.
Die Aufgabe der vorliegenden Erfindung besteht darin, ein effizientes und sicheres Konzept zur Ver- bzw. Entschlüsselung von Multimediadaten zu schaffen.
Diese Aufgabe wird durch ein Verfahren zum Erzeugen eines verschlüsselten Multimediadatenstroms nach Anspruch 1, durch ein Verfahren zum Entschlüsseln eines verschlüsselten Multimediadatenstroms nach Anspruch 17, durch eine Vorrichtung zum Erzeugen eines verschlüsselten Multimediadatenstroms nach Anspruch 27 und durch eine Vorrichtung zum Entschlüsseln eines verschlüsselten Multimediadatenstroms nach Anspruch 28 gelöst.
Der vorliegenden Erfindung liegt die Erkenntnis zugrunde, daß zum sicheren und effizienten Verschlüsseln ein sogenanntes hybrides Verschlüsselungsverfahren eingesetzt werden muß, wobei das schnellere z. B. symmetrische Verschlüsselungsverfahren oder Scramblingverfahren zum Ver- bzw. Entschlüsseln der Nutzdaten selbst, d. h. der "Payload"-Daten, eingesetzt wird, während das langsamere asymmetrische Ver- schlüsselungskonzept nur verwendet wird, um den Nutzdaten- Schlüssel für das z. B. symmetrische Verschlüsselungskonzept zu verschlüsseln und in dieser verschlüsselten Form zu einem Benutzer zu übertragen, damit er den verschlüsselten Nutzdatenstrom wieder entschlüsseln kann. Weiterhin soll der verschlüsselte Nutzdatenstrom, der einerseits eine Nutzdatei sein könnte oder aber ein durchgehender Datenstrom sein kann, gegen unerlaubte Manipulationen gesichert werden. Um dies auf effiziente und möglichst Rechenzeit-sparende Art und Weise zu verwirklichen, wird in das asymmetrische Verschlüsselungsverfahren zum Verschlüsseln des Nutzdaten- Schlüssels der Nutzdatenstrom selbst mit einbezogen.
An dieser Stelle sei darauf hingewiesen, daß Nutzdaten allgemein Multimediadaten, d. h. Audiodaten, Viedeodaten oder eine Kombination aus Audiodaten und Videodaten, aber auch z. B. Textdaten und sogar Binärdaten, wie z. B. ausführbare Programme, umfassen. Im nachfolgenden wird der Gegenstand der vorliegenden Erfindung aus Zweckmäßigkeits- günden jedoch anhand von Multimediadaten dargelegt. Es ist jedoch offensichtlich, daß sämtliche Nutzdaten, für die es ein Verschlüsselungsinteresse gibt, durch die erfindungsgemäßen Vorrichtungen und Verfahren verarbeitet werden können.
Vorzugsweise wird eine Hash-Summe eines Teils des Multimediadatenstroms erzeugt. Dieser Teil könnte zum einen lediglich der Anfangsblock des Multimediadatenstroms sein, zum anderen aber auch Teile der verschlüsselten bzw. unverschlüsselten Multimediadaten selbst umfassen.
Ein Ausgabewert in dem Anfangsblock, der dem Kunden zusammen mit den zumindest teilweise verschlüsselten Multimediadaten in Form des Multimediadatenstroms übermittelt wird, stellt gewissermaßen eine verschlüsselte Version des Multimediadaten-Schlüssels dar, wobei, um diesen Ausgabewert wieder korrekt zu entschlüsseln, um den Multimediadaten-Schlüssel zu erhalten, neben dem Schlüssel für das asymmetrische Verschlüsselungsverfahren auch vom Provider erzeugte indivi- duelle Daten, wie z. B. Lizenzdaten, die sich auf die Art und Weise beziehen, wie ein Benutzer die verschlüsselten Multimediadaten überhaupt benutzen darf, als auch Teile der Multimediadaten selbst sein können. Führt ein Benutzer daher Manipulationen an dem Anfangsblock durch, indem er beispielsweise das Verfallsdatum seiner Lizenz, ein bestimmtes Multimediastück zu verwenden, verändert, so kann er keinesfalls mehr den korrekten Schlüssel zum Entschlüsseln der verschlüsselten Multimediadaten ermitteln, da keine korrekte Entschlüsselung des Ausgabewerts mehr möglich ist.
Ein wesentlicher Vorteil des Verfahrens besteht also darin, daß, sobald jemand den Anfangsblock verändert, sich auch die Hash-Summe über den Anfangsblock ändert. Dadurch ist es nicht mehr möglich, den Schlüssel zum Entschlüsseln der Multimediadaten korrekt zu ermitteln. Somit führt jegliche Änderung am Anfangsblock automatisch zur Zerstörung der Multimediadaten selber.
Diese "implizite" Sicherung des Anfangsblocks umfaßt keine Verschlüsselung des Anfangsblocks, weshalb derselbe auch nicht entschlüsselt werden muß, was bei den Abspielvorrichtungen wiederum zu Ressourceneinsparungen ausgenutzt werden kann. Natürlich wäre eine solche Verschlüsselung des Anfangsblocks ohne weiteres möglich, wenn der Wunsch danach besteht.
Analog dazu führt, wenn verschlüsselte oder unverschlüsselte Multimediadaten selbst in die Verschlüsselung des Multimediadaten-Schlüssels mit einbezogen werden, eine Veränderung an den Multimediadaten zu einer automatischen Zerstörung der gesamten Multimediadaten.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Zeichnungen detailliert erläutert. Es zeigen:
Fig. 1 einen Multimediadaten-Strom, der gemäß der vorlie- genden Erfindung erzeugt werden kann;
Fig. 2 eine detailliertere Darstellung des Anfangsblocks _ und des Nutzdatenblocks des verschlüsselten Multimediadatenstroms ;
Fig. 3 eine Auswahl bestimmter Einträge in die einzelnen Unterblöcke des Anfangsblocks;
Fig. 4 ein Flußdiagramm für das Verfahren zum Erzeugen eines verschlüsselten Multimediadatenstroms gemäß der vorliegenden Erfindung, das vorzugsweise bei einem Distributor, d. h. einem Lieferanten, von Multimediadaten ausgeführt wird; und
Fig. 5 ein Verfahren zum Entschlüsseln eines verschlüsselten Multimediadatenstroms gemäß der vorliegenden Erfindung, das vorzugsweise bei einem Kunden oder Benutzer der Multimediadaten ausgeführt wird.
Fig. 1 zeigt einen verschlüsselten Multimediadatenstrom 10, der einen Anfangsblock oder Header 12 und einen Nutzdatenblock 14, d. h. einen Block mit verschlüsselten Multimediadaten, aufweist. Der Nutzdatenblock 14 umfaßt verschlüsselte Abschnitte 16 und unverschlüsselte Abschnitte 18 zwischen den verschlüsselten Abschnitten 16. Außerdem umfaßt ein Multimediadatenstrom, der gemäß der vorliegenden Erfindung erzeugt werden kann, einen weiteren unverschlüsselten Abschnitt 20, der auf den Anfangsblock 12 folgt und vor einem verschlüsselten Abschnitt 16 angeordnet ist.
Üblicherweise sind die zu verschlüsselten Multimediadaten auf irgendeine Art und Weise codiert, wie z. B. nach einem MPEG-Standard, wie z. B. MPEG-2 AAC, MPEG-4 Audio oder MPEG Layer-3. Daher ist es ausreichend, gewisse Abschnitte der zu verschlüsselten Multimediadaten zu verschlüsseln. Dies führt zu einem wesentlich verringerten Verarbeitungsaufwand sowohl beim Provider, der die Daten verschlüsselt, als auch beim Kunden, der die Daten wieder entschlüsseln muß. Außerdem wird durch die lediglich teilweise Verschlüsselung der Multimediadaten der Hörgenuß bzw. der Sehgenuß eines Benutzers, der__lediglich die unverschlüsselten Multimediadaten verwendet, durch die ständig auftretenden verschlüsselten Blöcke stark beeinträchtigt.
Obwohl Fig. 1 einen verschlüsselten Multimediadatenstrom zeigt, bei dem der Anfangsblock 12 am Anfang des verschlüsselten Multimediadatenstroms angeordnet ist, soll sich diese Anordnung von Anfangsblock und Nutzdatenblock nicht auf die Übertragung des verschlüsselten Multimediadatenstroms beziehen. Der Ausdruck "Anfangsblock" soll lediglich zum Ausdruck bringen, daß eine Entschlüsselungsvorrichtung, die den verschlüsselten Multimediadatenstrom entschlüsseln möchte, zunächst zumindest Teile des Anfangsblocks benötigt, bevor die Multimediadaten selbst entschlüsselt werden können. Je nach Übertragungsmedium könnte der Anfangsblock irgendwo auch innerhalb des Nutzdatenblocks angeordnet sein bzw. durchaus nach bestimmten Teilen des Nutzdatenblocks empfangen werden, wenn beispielsweise an eine Paket-orientierte Übertragung des Multimediadatenstroms gedacht wird, bei der unterschiedliche Pakete, von denen eines den Anfangsblock enthalten kann und ein anderes einen Teil des Nutzdatenblocks enthalten kann, über unterschiedliche physische Übertragungswege übertragen werden, derart, daß die Empfangsreihenfolge ganz und gar nicht der Sendereihenfolge entsprechen muß. Eine Entschlüsselungsvorrichtung muß in diesem Fall jedoch in der Lage sein, die empfangenen Pakete zu speichern und wieder zu ordnen, derart, daß Informationen aus dem Anfangsblock extrahiert werden, um mit dem Entschlüsseln zu beginnen. Der verschlüsselte Multimediadatenstrom könnte ferner in Form einer Datei vorliegen oder aber auch in Form eines tatsächlichen Datenstroms, wenn beispielsweise an eine Live-Über- tragung eines Multimediaereignisses gedacht wird. Diese Anwendung wird insbesondere beim digitalen Benutzer-selektiven Rundfunk auftreten. Die Länge eines verschlüsselten Abschnitts 16 wird durch einen Wert Menge 22 dargestellt, während der Abstand im verschlüsselten Multimediadatenstrom von dem Beginn eines verschlüsselten Abschnitts 16 bis zum Beginn des nächsten verschlüsselten Abschnitts 16 mit Schritt 24 bezeichnet wird. Die Länge des weiteren verschlüsselten Abschnitts 20 wird durch einen Wert Erster Schritt 26 angegeben.
Diese Werte 22, 24 und 26 werden selbstverständlich für ein korrektes Entschlüsseln der Multimediadaten in einer Entschlüsselungsvorrichtung benötigt, weshalb dieselben in den Anfangsblock 12 eingetragen werden müssen, wie es später erläutert wird.
Fig. 2 zeigt eine detailliertere Darstellung des verschlüsselten Multimediadatenstroms 10, der aus dem Anfangsblock 12 und dem Nutzdatenblock 14 besteht. Der Anfangsblock 12 ist in mehrere Unterblöcke unterteilt, die im einzelnen insbesondere bezugnehmend auf Fig. 3 erläutert werden. Es sei darauf hingewiesen, daß die Anzahl und Funktion der Unterblöcke beliebig erweitert werden kann, in Fig. 2 sind daher lediglich beispielhaft einzelne Unterblöcke des Anfangsblocks 12 aufgeführt. Derselbe umfaßt, wie es in Fig. 2 gezeigt ist, einen sogenannten Crypt-Block 29, der allgemein gesagt für das Verschlüsseln der Multimediadaten relevante Informationen aufweist. Weiterhin umfaßt der Anfangsblock 12 einen sogenannten Lizenz-Block 30, der Daten aufweist, die sich auf die Art und Weise beziehen, wie ein Benutzer den verschlüsselten Multimediadatenstrom verwenden kann bzw. darf. Der Anfangsblock 12 umfaßt ferner einen Nutzdateninfo-Block 32, der Informationen bezüglich des Nutzdatenblocks 14 sowie generelle Informationen über den Anfangsblock 12 selbst umfassen kann. Weiterhin kann der Anfangsblock 12 einen Alter-Anfangsblock-Block 34 aufweisen, der eine sogenannte rekursive Anfangsblock-Struktur ermöglicht. Dieser Block versetzt den Benutzer, der neben einer Entschlüsselungsvorrichtung auch eine Verschlüsselungsvorrichtung hat, in die Lage, einen verschlüsselten Multimediadatenstrom für andere in seinem Besitz befindliche Abspielgeräte umzuforma- tieren, ohne die ursprünglichen vom Distributor gelieferten Anfangsblockinformationen zu verlieren bzw. zu modifizieren. Je nach Anwendungsbereich können noch weitere Unterblöcke, wie z. B. ein iP-lnformation-Block (IP = Intellectual Pro- perty = Geistiges Eigentum) nach ISO/IEC 14496-1, MPEG-4, Systems, 1998, der UrheberrechtsInformationen umfaßt, zu dem Anfangsblock 12 hinzugefügt werden.
Wie es in der Technik üblich ist, kann jedem Block eine interne Blockstruktur zugewiesen werden, die zunächst einen Blockidentifikator fordert, die dann die Länge des Unterblocks umfaßt, und die dann schließlich die Block-Nutzdaten selbst aufführt. Damit erhält der verschlüsselte Multimediadatenstrom und insbesondere der Anfangsblock des verschlüsselten Multimediadatenstroms einer erhöhte Flexibilität, derart, daß auf neue Anforderungen insoweit reagiert werden kann, daß zusätzliche Unterblöcke hinzugefügt werden bzw. bestehende Unterblöcke weggelassen werden können.
Fig. 3 gibt eine Übersicht über die Block-Nutzdaten der einzelnen in Fig. 2 dargestellten Unterblöcke.
Zunächst wird auf den Crypt-Block 28 eingegangen. Derselbe enthält einen Eintrag für einen Multimediadaten-Verschlüsselungsalgorithmus 40, der den bei einem bevorzugten Ausführungsbeispiel verwendeten symmetrischen Verschlüsselungsalgorithmus identifiziert, der beim Verschlüsseln der Multimediadaten verwendet worden ist. Der Eintrag 40 dürfte ein Index für eine Tabelle sein, derart, daß eine Entschlüsselungsvorrichtung nach Lesen des Eintrags 40 in der Lage ist, denselben Verschlüsselungsalgorithmus aus einer Vielzahl von Verschlüsselungsalgorithmen auszuwählen, den die Verschlüsselungsvorrichtung verwendet hat. Der Crypt-Block 28 umfaßt ferner den Eintrag Erster Schritt 26, den Eintrag Schritt 24 und den Eintrag Menge 22, die bereits in Verbindung mit Fig. 1 dargestellt worden sind. Diese Einträge in dem Anfangsblock versetzen eine Entschlüsselungsvorrichtung in die Lage, einen verschlüsselten Multimediadatenstrom entsprechend unterzugliedern, um eine korrekte Entschlüsselung durchführen zu können.
Der Crypt-Block 28 enthält ferner einen Eintrag für den Distributor bzw. Provider bzw. Lieferanten 42, der ein Code für den Distributor ist, der den verschlüsselten Multimediadatenstrom erzeugt hat. Ein Eintrag Benutzer 44 identifiziert den Benutzer, der von dem Distributor, der durch den Eintrag 42 identifiziert ist, den verschlüsselten Multimediadatenstrom auf irgendeine Art und Weise erhalten hat. Eine mögliche Verwendung dieser Kennungen ist es,- die Benutzerkennung gerätespezifisch durchzuführen. Der Eintrag Benutzer würde dann die Seriennummer eines PC, eines Laptops, eines Auto-HiFi-Geräts, einer Heim-Stereoanlage etc. umfassen, die ein Abspielen nur auf dem speziellen Gerät zuläßt. Zur weiteren Erhöhung der Flexibilität und/oder Sicherheit könnte statt der Seriennummer, die bei jedem Hersteller unterschiedlich aussieht, die aber zufällig identisch sein könnten, eine spezielle Kennung, wie z. B. eine logische Verknüpfung der Festplattengröße mit der Prozessornummer etc. beim Beispiel eines PC, eingesetzt werden.
Ein Eintrag 46 enthält einen Ausgabewert, auf den später detailliert eingegangen wird. Dieser Ausgabewert stellt allgemein gesagt eine verschlüsselte Version des Multimediadaten-Schlüssels dar, der in Verbindung mit dem durch den Eintrag 40 identifizierten Multimediadaten-Verschlüsselungsalgorithmus benötigt wird, um die in dem Nutzdatenblock 14 vorhandenen verschlüsselten Multimediadaten (Abschnitte 16 von Fig. 1) korrekt zu entschlüsseln. Um eine ausreichende Flexibilität für zukünftige Anwendungen zu haben, sind ferner die beiden Einträge Ausgabewertlänge 48 und Ausgabewertmaske 50 vorgesehen. Der Eintrag Ausgabewertlänge 48 gibt an, welche Länge der Ausgabewert 46 tatsächlich hat. Um ein flexibles Anfangsblockformat zu erhalten, sind jedoch in dem Anfangsblockformat für den Ausgabewert mehr Byte vorge- sehen als ein Ausgabewert derzeit tatsächlich hat. Die Ausgabewertmaske 50 gibt daher an, wie ein kürzerer Ausgabewert auf einen längeren Ausgabewertplatz gewissermaßen verteilt wird.. Ist die Ausgabewertlänge beispielsweise halb so groß wie der verfügbare Platz für den Ausgabewert, so könnte die Ausgabewertmaske derart gestaltet sein, daß die erste Hälfte der Ausgabewertmaske gesetzt ist, während die zweite Hälfte abgedeckt ist. Dann würde der Ausgabewert einfach in den von der Syntax für den Anfangsblock vorgesehenen Raum eingetragen werden und die erste Hälfte einnehmen, während die andere Hälfte aufgrund der Ausgabewertmaske 50 ignoriert wird.
Im nachfolgenden wird auf den Lizenz-Block 30 des Anfangsblocks 12 eingegangen. Derselbe umfaßt einen Eintrag Bitmaske 52. Dieser Eintrag kann bestimmte spezielle Informationen für das Abspielen bzw. für die generelle Art der Verwendung der verschlüsselten Multimediadaten haben. Insbesondere könnte hiermit einer Entschlüsselungsvorrichtung mitgeteilt werden, ob bzw. ob nicht die Nutzdaten lokal abgespielt werden können. Weiterhin könnte hier signalisiert werden, ob das Herausforderungs-Antwort-Verfahren zum Verschlüsseln eingesetzt worden ist, das in dem eingangs erwähnten Deutschen Patent DE 196 25 635 Cl beschrieben ist und einen effizienten Datenbankzugriff ermöglicht.
Ein Eintrag Verfallsdatum 54 gibt den Zeitpunkt an, zu dem die Erlaubnis, den verschlüsselten Multimediadatenstrom zu entschlüsseln, erlischt. Eine Entschlüsselungsvorrichtung wird in diesem Fall den Eintrag Verfallsdatum 54 prüfen und mit einer eingebauten Zeitmeßeinrichtung vergleichen, um im Falle, daß das Verfallsdatum bereits überschritten ist, keine Entschlüsselung des verschlüsselten Multimediadatenstroms mehr durchzuführen. Dies erlaubt es einem Provider, auch zeitlich begrenzt verschlüsselte Multimediadaten zur Verfügung zu stellen, was den Vorteil einer wesentlich flexibleren Handhabung und auch Preisgestaltung ermöglicht. Diese Flexibilität wird weiter durch einen Eintrag Anfangsdatum 56 unterstützt, in dem spezifiziert ist, ab wann eine verschlüsselte Multimediadatei entschlüsselt werden darf. Eine Verschlüsselungsvorrichtung wird den Eintrag Anfangsdatum mit__ihrer eingebauten Uhr vergleichen, um erst dann eine Entschlüsselung der verschlüsselten Multimediadaten durchzuführen, wenn der aktuelle Zeitpunkt später als das Anfangsdatum 56 ist.
Ein Eintrag Erlaubte Abspielanzahl 58 gibt an, wie oft der verschlüsselte Multimediadatenstrom entschlüsselt, d. h. abgespielt werden darf. Dies erhöht weiter die Flexibilität des Providers, derart, daß er nur eine bestimmte Anzahl des Abspielens beispielsweise gegen eine bestimmte Summe zuläßt, die kleiner ist als eine Summe, die für die unbeschränkte Nutzung des verschlüsselten Multimediadatenstroms anfallen würde.
Zur Verifizierung bzw. Unterstützung des Eintrags Erlaubte Abspielanzahl 58 umfaßt der Lizenz-Block 30 ferner einen Eintrag Tatsächliche Abspielanzahl 60, der nach jedem Entschlüsseln des verschlüsselten Multimediadatenstroms beispielsweise um Eins inkrementiert werden könnte. Eine Entschlüsselungsvorrichtung wird daher immer überprüfen, ob der Eintrag Tatsächliche Abspielanzahl kleiner als der Eintrag Erlaubte Abspielanzahl ist. Wenn dies der Fall ist, wird eine Entschlüsselung der Multimediadaten durchgeführt. Wenn dies nicht der Fall ist, wird keine Entschlüsselung mehr ausgeführt.
Analog zu den Einträgen 58 und 60 sind die Einträge Erlaubte Kopieanzahl 62 und Tatsächliche Kopieanzahl 64 implementiert. Durch die beiden Einträge 62 und 64 wird sichergestellt, daß ein Benutzer der Multimediadaten dieselben lediglich so oft kopiert, wie es ihm vom Provider erlaubt wird, bzw. so oft, wie er beim Kauf der Multimediadaten bezahlt hat. Durch die Einträge 58 bis 64 wird ein effektiver Urheberrechtsschutz sichergestellt, und kann eine Selektion zwischen privaten Nutzern und gewerblichen Nutzern erreicht werden, beispielsweise, indem die Einträge Erlaubte Abspielanzahl 58 und Erlaubte Kopieanzahl 62 auf einen kleinen Wert eingestellt werden.
Die Lizenzierung könnte z. B. so gestaltet sein, daß eine bestimmte Anzahl von Kopien (Eintrag 62) des Originals erlaubt ist, während keine Kopien einer Kopie zulässig sind. Der Anfangsblock einer Kopie würde dann im Gegensatz zum Anfangsblock des Originals als Eintrag Erlaubte Kopieanzahl eine Null haben, derart, daß diese Kopie von einer ordnungsgemäßen Ver/Entschlüsselungsvorrichtung nicht mehr kopiert wird.
Bei dem hier gezeigten Beispiel für ein Multimediadatenschutzprotokoll (MMP; MMP = Multimedia Protection Protcol) enthält der Anfangsblock 12 ferner einen Nutzdaten-Informationsblock 32, der hier lediglich zwei Block-Nutzdateneinträge 66 und 68 hat, wobei der Eintrag 66 eine Hash-Summe über den gesamten Anfangsblock enthält, während der Eintrag 68 den Typ des Hash-Algorithmus identifiziert, der zum Bilden der Hash-Summe über den gesamten Anfangsblock verwendet worden ist.
In diesem Zusammenhang sei beispielsweise auf das Fachbuch "Applied Cryptography" , Second Edition, John Wiley & Sons, Inc. von Bruce Schneier (ISBN 0 471-11709-9) verwiesen, das eine ausführliche Darstellung symmetrischer Verschlüsselungsalgorithmen, asymmetrischer Verschlüsselungsalgorithmen und Hash-Algorithmen umfaßt.
Der Anfangsblock 12 umfaßt schließlich den Alter-Anfangsblock-Block 34, der neben den Synchronisationsinformationen, die in Fig. 3 nicht dargestellt sind, den Eintrag Alter Anfangsblock 70 aufweist. In den Eintrag Alter-Anfangsblock 70 kann, wenn ein Benutzer selbst eine Verschlüsselung durchführt und somit einen neuen Anfangsblock 12 erzeugt, der alte Anfangsblock vom Provider bewahrt werden, um keine wesentlichen Informationen zu verlieren, die der Provider in den Anfangsblock eingetragen hat. Dazu könnten beispielsweise Urheberinformationen (IP-Information-Block) frühere Benutzerinformationen und Distributoreninformationen zählen, die eine Zurückverfolgung einer Multimediadatei, die beispielsweise mehrmals von unterschiedlichen Geräten ent-/ver-schlüsselt worden ist, auf den ursprünglichen Anbieter transparent ermöglichen, wobei UrheberInformationen bewahrt werden. Damit ist es möglich, jederzeit zu überprüfen, ob eine verschlüsselte Multimediadatei legal oder illegal erworben worden ist.
Nachdem auf das Format des verschlüsselten Multimediadatenstroms und verschiedene Funktionalitäten von Verschlüsse- lungs- und Entschlüsselungsvorrichtungen eingegangen worden ist, wird nun anhand von Fig. 4 das erfindungsgemäße Verfahren zum Verschlüsseln von Multimediadaten dargelegt. Bei einer bevorzugten Anwendung der vorliegenden Erfindung wird das erfindungsgemäße Verschlüsselungsverfahren beim Distributor ausgeführt. Der Distributor führt bevorzugterweise ein hybrides Verschlüsselungsverfahren aus, d. h. ein symmetrisches Verschlüsselungsverfahren zum Verschlüsseln der Multimediadaten und ein asymmetrisches Verschlüsselungsverfahren zum Verschlüsseln des Multimediadaten-Schlüssels.
Ein Kunde oder Benutzer, der Multimediadaten von einen Distributor erwerben will, tritt zunächst mit dem Distributor in Verbindung und könnte ihm beispielsweise seine Kreditkartennummer mitteilen, von der der Distributor fällige Geldbeträge abbucht. Daraufhin erhält der Kunde vom Distributor eine Tabelle der symmetrischen Verschlüsselungsverfahren. Außerdem tauschen Distributor und Kunde jeweils ihre öffentlichen Schlüssel aus. Wenn der Benutzer nun ein bestimmtes Multimediawerk vom Distributor bestellt, so führt der Distributor eine kundenselektive Verschlüsselung für diesen Kunden durch.
Im einzelnen könnten die Schritte zum Erzeugen des verschlüsselten Multimediadatenstroms folgendermaßen aussehen. Der Distributor erstellt zunächst den Anfangsblock 12 für die Multimediadatei soweit es bisher möglich ist (100). Wie es aus Fig. 3 ersichtlich ist, liegt zu diesem Zeitpunkt noch, nicht der Ausgabewert vor. Daher wird im Schritt 100, in dem der Anfangsblock 12 soweit als möglich erstellt wird, der Eintrag für den Ausgabewert freigelassen. Es existieren jedoch hier schon sämtliche anderen Einträge in den Crypt- Block und sämtliche anderen Einträge in den Lizenz-Block. Die Hash-Summe oder je nach dem die digitale Unterschrift in dem Eintrag 66 über den gesamten Anfangsblock existiert dagegen noch nicht, weshalb auch dieser Eintrag frei bleibt. Auch der Eintrag Alter-Anfangsblock 70 wird sehr wahrscheinlich, wenn die Multimediadatei vom Distributor zum ersten Mal verschlüsselt werden, frei bleiben. Hat der Distributor die verschlüsselte Multimediadatei jedoch von einem anderen Distributor erworben, so könnte der Eintrag 70 bereits gefüllt sein. In einem Schritt 102 ermittelt der Distributor einen Multimediadatenschlüssel K, der zusammen mit dem Multimediadaten-Verschlüsselungsalgorithmus, der durch den Eintrag 40 (Fig. 3) identifiziert ist, eine Verschlüsselung der Multimediadaten erlaubt, die in einem Schritt 104 durchgeführt wird.
Gemäß der vorliegenden Erfindung wird eine Hash-Summe über den Anfangsblock gebildet, wobei bestimmte Teile einen vordefinierten Wert haben (Schritt 106). Die detaillierte Darstellung des Anfangsblocks in Fig. 3 enthält am rechten Rand eine Spalte 107, die veranschaulichen soll, welche Teile bzw. Einträge in den Anfangsblock 12 beim Bilden einer Hash-Summe im Schritt 106 (Fig. 4) einen vordefinierten Wert erhalten. Einen vordefinierten Wert erhalten insbesondere der Eintrag Ausgabewert 46, der Eintrag Tatsächliche Abspielanzahl 60, der Eintrag Tatsächliche Kopieanzahl 64 und der Eintrag Hash-Summe über den Anfangsblock 66 sowie unter Umständen der Eintrag Alter-Anfangsblock 70, wie es durch das gepunktete Kreuzchen für den Eintrag 70 dargestellt ist. Bestimmte Teile des Anfangsblocks müssen einen vordefinierten Wert zugewiesen bekommen, wenn die Hash-Summe im Schritt 106 gebildet wird, da diese noch nicht feststehen (Ausgabewert 46) bzw. von einer Entschlüsselungsvorrichtung geändert werden (Einträge 60 und 64). Der Eintrag 66, d. h. die Hash-Summe über den Anfangsblock, steht ferner noch nicht fest, da in dieselbe selbstverständlich auch der Ausgabewert 46 eingeht.
Die Einträge Distributor 42, Benutzer 44 sowie die Einträge in den Lizenz-Block 30 werden jedoch beim Bilden der Hash- Summe im Schritt 106 (Fig. 4) mit einbezogen, wodurch bereits eine Personalisierung bzw. eine Absicherung der Lizenz-Block-Einträge erreicht wird, da die in dem Schritt 106 erhaltene Hash-Summe mit dem Multimediadaten-Schlüssel verknüpft wird, um einen Basiswert zu erhalten (Schritt 108).
Daran anschließend wird der im Schritt 108 erhaltene Basiswert mittels des öffentlichen Schlüssels (Ö) des Kunden asymmetrisch verschlüsselt (Schritt 110). Um den verschlüsselten Multimediadatenstrom in ein übertragbares Format zu bringen, wird schließlich noch der Anfangsblock vervollständigt (Schritt 112), derart, daß der Ausgabewert 46 in den bereits im Schritt 100 erstellten Anfangsblock eingetragen wird.
In Abweichung von dem in Fig. 4 dargestellten Ausführungsbeispiel kann die Schrittreihenfolge vertauscht werden. So könnte beispielsweise zunächst die gesamte Verschlüsselung des Multimediadatenschlüssels durchgeführt werden, woraufhin die Verschlüsselung der Multimediadaten durchgeführt wird. Ferner könnte die Hash-Summe über den Anfangsblock ermittelt werden, bevor der Multimediadatenschlüssel generiert wird. Weitere Variationen sind möglich. Selbstverständlich kann der Schritt 108 erst dann durchgeführt werden, wenn die Hash-Summe ermittelt worden ist. Darüberhinaus kann der Schritt 110 erst dann durchgeführt werden, wenn der Basiswert vorliegt.
Vorzugsweise wird zum Verschlüsseln der Multimedia-Daten mit dem Multimediadaten-Schlüssel im Schritt 104 ein symmetrisches Verschlüsselungsverfahren eingesetzt, da hier unter Umständen relativ große Mengen an Daten ver- bzw. entschlüsselt- werden müssen. Symmetrische Verschlüsselungsverfahren arbeiten, wie es bekannt ist, schneller als asymmetrische Verschlüsselungsverfahren, wie sie im Schritt 110 zum Verschlüsseln des Multimediadatenschlüssels eingesetzt werden.
Ferner wird es bevorzugt, daß der Multimediadaten-Schlüssel K mittels eines Zufallszahlengenerators erzeugt wird, derart, daß der Basiswert, der in dem Schritt 108 erzeugt wird, für denselben Kunden jedesmal eine andere Form annimmt, um es einem Angreifer auf das cryptographische System so schwer als möglich zu machen.
Die Verknüpfungsoperation, um die Hash-Summe mit dem Multimediadaten-Schlüssel K zu verknüpfen, sollte, wie es bezugnehmend auf Fig. 5 noch erläutert wird, eine selbstinverse Verknüpfung sein. Eine solche selbstinverse Verknüpfung wäre die XOR- (Exklusiv-Oder-) Verknüpfung. Selbstinvers bedeutet, daß ein zweimaliges Anwenden dieser Verknüpfung zu einem Ergebnis führt, das gleich dem Ausgangswert ist. Außerdem ist es möglich, daß die Verknüpfungs-Funktion aus Fig. 5 die inverse Funktion derjenigen aus Fig. 4 ist. Die Verknüpfungsfunktion muß daher lediglich umkehrbar sein, d. h. zu derselben muß eine Umkehrfunktion existieren.
Im Schritt 110 wird gemäß der vorliegenden Erfindung ein asymmetrisches Verschlüsselungsverfahren ausgeführt. Wie es bekannt ist, existieren bei einem asymmetrischen Verschlüsselungsverfahren zwei Schlüssel, mit denen eine Ver- bzw. Entschlüsselung möglich ist, die jedoch voneinander unterschiedlich sind. Ein Schlüssel wird als privater Schlüssel P (Privat Key) bezeichnet, während der andere Schlüssel als der öffentliche Schlüssel Ö (Public Key) bezeichnet wird. Allgemein gesagt haben asymmetrische Verschlüsselungsverfahren die Eigenschaft, daß zu verschlüsselnde Daten, die mittels des privaten Schlüssels verschlüsselt worden sind, mit dem öffentlichen Schlüssel wieder entschlüsselt werden können. Analog dazu können zu verschlüsselnde Daten, die mit dem öffentlichen Schlüssel verschlüsselt worden sind, wieder mit_dem privaten Schlüssel entschlüsselt werden. Daraus ist zu sehen, daß die privaten und öffentlichen Schlüssel prinzipiell gegeneinander austauschbar sind.
Ein Aspekt der vorliegenden Erfindung besteht darin, daß der Anfangsblock über die Schritte 106 und 108 in die Verschlüsselung des Multimediadatenschlüssels miteinbezogen wird. Alternativ könnten jedoch auch Teile des Nutzdatenblocks miteinbezogen werden, wodurch aufgrund unerlaubter Manipulationen der Nutzdaten der gesamte Multimediadatenstrom unbrauchbar werden würde, da es dann nicht mehr möglich ist, den Multimediadatenschlüssel in der Entschlüsselungsvorrichtung zu berechnen.
Obwohl im Schritt 106 davon gesprochen wird, daß eine Hash- Summe über den Anfangsblock gebildet wird, sei darauf hingewiesen, daß jede Verarbeitung eines Teils des Multimediadatenstroms, um Informationen abzuleiten, die den Teil des Multimediadatenstrom kennzeichnen, eingesetzt werden könnte. Je aufwendiger der Hash-Algorithmus ist, der hier verwendet wird, umso sicherer wird der verschlüsselte Multimediadatenstrom gegenüber Angreifern, die ihn knacken wollen, um beispielsweise die Lizenzinformationen bzw. die Distributoroder Benutzer-Informationen in ihrem (unerlaubten) Sinne zu modifizierten.
Im nachfolgenden wird auf Fig. 5 Bezug genommen, die ein Flußdiagramm des Entschlüsselungsverfahrens zeigt, das möglicherweise von einem Kunden durchgeführt wird. In einem Schritt 120 liest der Kunde zunächst den Ausgabewert aus dem Anfangsblock des verschlüsselten Multimediadatenstroms. Er führt daraufhin eine Entschlüsselung dieses Ausgabewerts mittels der entsprechenden asymmetrischen Entschlüpsselung durch (Schritt 122). Hierauf bildet die Entschlüsselungsvorrichtung beim Kunden wieder eine Hash-Summe über den An- fangsblock, wobei die bestimmten Teile, die beim Verschlüsseln einen vordefinierten Wert hatten, in einem Schritt 124 ebenfalls den gleichen vordefinierten Wert erhalten. Anschließend wird die Hash-Summe mit dem entschlüsselten Ausgabewert (Schritt 122) verknüpft, woraus sich der Multimediadatenschlüssel ergibt (Schritt 126). In einem Schritt 128 werden schließlich die verschlüsselten Multimediadaten mit dem in dem Schritt 126 erhaltenen Multimediadatenschlüssel entschlüsselt.
Es zeigt sich, daß das Entschlüsselungsverfahren im wesentlichen die Umkehrung des Verschlüsselungsverfahrens, das anhand des Flußdiagramms von Fig. 4 beschrieben worden ist, darstellt. Selbstverständlich können auch bei dem in Fig. 5 gezeigten Entschlüsselungsverfahren mehrere Schritte vertauscht werden. So könnte beispielsweise zunächst die Hash- Summe über den Anfangsblock gebildet werden (Schritt 124), wonach der Ausgabewert mit dem öffentlichen Schlüssel entschlüsselt wird (Schritt 122). Auch das Lesen des Ausgabewerts aus dem Anfangsblock (Schritt 120) können beispielsweise erst nach dem Schritt 124, jedoch unbedingt vor dem Schritt 126 durchgeführt werden. Auch Schritt 128 ist erst möglich, nachdem der Schritt 126 durchgeführt worden ist, da der den Multimediadatenschlüssel ergibt.
Das in Fig. 5 gezeigte Entschlüsselungsverfahren bringt anhand des Schritts 124 noch einmal deutlich zum Ausdruck, was passiert, wenn ein Kunden den Anfangsblock 12 modifiziert hat, der ja üblicherweise unverschlüsselt ist und ohne weiteres für Angriffe zugänglich ist. Eine Änderung der Lizenzinformationen, beispielsweise des Anfangs- und des Enddatums würde jedoch unweigerlich dazu führen, daß die Hash-Summe über den Anfangsblock, die im Schritt 124 gebildet wird, einen anderen Wert hat wie die Hash-Summe die im Schritt 106 (Fig. 4) während der Verschlüsselung gebildet worden ist. Die erneute Verknüpfung der Hash-Summe im Schritt 126 (Fig. 5) wird daher nicht mehr zu dem korrekten Multimediadatenschlüssel führen, da die beiden Hash-Summen, d. h. die Hash-Summe während des Verschlüsseins und die Hash-Summe während des Entschlüsseins, voneinander unterschiedlich sind. Somit sind die gesamten Multimediadaten unbrauchbar, da _sie nicht mehr korrekt entschlüsselt werden können, da es nicht mehr möglich ist, aufgrund der Manipulation am Anfangsblock den Multimediadatenschlüssel zu berechnen, den die Verschlüsselungsvorrichtung eingesetzt hat. Jede Änderung am Anfangsblock führt somit automatisch zur Zerstörung der Multimediadaten selbst.

Claims

Patentansprüche
Verfahren zum Erzeugen eines Nutzdatenstroms (10), der einen Anfangsblock (12) und einen Nutzdatenblock (14) mit verschlüsselten Nutzdaten aufweist, mit folgenden Schritten:
Generieren (102) eines Nutzdaten-Schlüssels für einen Nutzdaten-Verschlüsselungsalgorithmus zum Verschlüsseln von Nutzdaten;
Verschlüsseln (104) von Nutzdaten unter Verwendung des Nutzdaten-Schlüssels und des Nutzdaten-Verschlüsselungsalgorithmus, um einen verschlüsselten Abschnitt (16) des Nutzdatenblocks (14) des Nutzdatenstroms (10) zu erhalten;
Verarbeiten (106) eines Teils des Nutzdatenstroms (10), um Informationen abzuleiten, die den Teil des Nutzdatenstroms kennzeichnen;
Verknüpfen (108) der Informationen mit dem Nutzdatenschlüssel mittels einer invertierbaren logischen Verknüpfung, um einen Basiswert zu erhalten;
Verschlüsseln (110) des Basiswerts unter Verwendung eines Schlüssels von zwei zueinander unterschiedlichen Schlüsseln (P, Ö) mit einem asymmetrischen Verschlüsselungsverfahren, wobei die zwei unterschiedlichen Schlüssel der öffentliche (Ö) bzw. der private (P) Schlüssel für das asymmetrische Verschlüsselungsverfahren sind, um einen Ausgabewert (46) zu erhalten, der eine verschlüsselte Version des Nutzdatenschlüssels ist; und
Eintragen (112) des Ausgabewerts (46) in den Anfangsblock (12) des Nutzdatenstroms (10).
2. Verfahren nach Anspruch 1 , bei dem der Nutzdaten-Verschlüsselungsalgorithmus ein symmetrischer Verschlüsselungsalgorithmus ist.
3. Verfahren nach Anspruch 1 oder 2 , bei dem die invertierbare logische Verknüpfung selbst-invertierend ist und eine EXKLUSIV-ODER-Verknüpfung umfaßt.
4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der eine Schlüssel der zwei voneinander unterschiedlichen Schlüssel (P, Ö) der private Schlüssel (P) eines Erzeugers des Nutzdatenstroms ist oder der öffentliche Schlüssel (Ö) eines Konsumenten des Nutzdatenstroms ist ist.
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Teil des Nutz-Datenstroms, der verarbeitet wird (106), um die Informationen abzuleiten, zumindest einen Teil des Anfangsblocks (12) umfaßt.
6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Schritt des Verarbeitens (106) das Bilden einer Hash-Summe aufweist.
7. Verfahren nach einem der vorhergehenden Ansprüche, das ferner folgenden Schritt aufweist:
Identifizieren des Algorithmus, der im Schritt des Verarbeitens (106) verwendet wird, durch einen Eintrag (68) in den Anfangsblock.
8. Verfahren nach einem der vorhergehenden Ansprüche, das ferner folgenden Schritt aufweist:
Eintragen von Lizenzdaten (30) in den Anfangsblock (12), die sich darauf beziehen, in welcher Weise der Nutzdatenstrom (10) verwendet werden darf.
9. Verfahren nach Anspruch 8, bei dem die Lizenzdaten (30) angeben, wie oft der Nutzdatenstrom abgespielt werden darf (58) und wie oft er bereits abgespielt wurde (60).
10. Verfahren nach Anspruch 8 oder 9, bei dem die Lizenzdaten (30) angeben, wie oft der Inhalt des Nutzdatenstroms kopiert werden darf (62), und wie oft er bereits kopiert worden ist (64).
11. Verfahren nach einem der Ansprüche 8 bis 10, bei dem die Lizenzdaten (30) angeben, ab wann der Nutzdatenstrom nicht mehr benutzt werden darf (54).
12. Verfahren nach einem der Ansprüche 8 bis 11, bei dem die Lizenzdaten (30) angeben, ab wann der Nutzdatenstrom entschlüsselt werden darf (56).
13. Verfahren nach einem der Ansprüche 8 bis 12, bei dem der Teil des Nutzdatenstroms, der verarbeitet wird, um die Informationen abzuleiten (106) die Lizenzdaten (30) umfaßt.
14. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Schritt des Verarbeitens ferner folgende Teilschritte aufweist:
Setzen des Eintrags (46) für den Ausgabewert in dem Anfangsblock (12) auf einen definierten Wert, und Verarbeiten (106) des gesamten Anfangsblocks einschließlich des auf einen definierten Wert gesetzten Eintrags (46).
15. Verfahren nach einem der vorhergehenden Ansprüche, das ferner folgende Schritte aufweist:
Identifizieren des Lieferanten (42) des Nutzdatenstroms durch einen Lieferanteneintrag (42) in den Anfangsblock ( 12 ) ; Identifizieren des Benutzers (44) des Nutzdatenstroms durch einen Benutzereintrag (44) in den Anfangsblock (12) des Nutzdatenstroms,
wobei der Lieferanteneintrag (42) und der Benutzereintrag (44) zu dem Teil des Nutzdatenstroms (10) gehören, der verarbeitet wird (106), um die Informationen abzuleiten.
16. Verfahren nach einem der vorhergehenden Ansprüche, das ferner folgenden Schritt aufweist:
Identifizieren des Nutzdaten-Verschlüsselungsalgorithmus durch einen Eintrag (40) in den Anfangsblock (12) des Nutzdatenstroms (10).
17. Verfahren zum Entschlüsseln eines verschlüsselten Nutzdatenstroms (10), der einen Anfangsblock (12) und einen Nutzdatenblock (14) mit verschlüsselten Nutzdaten aufweist, wobei der Anfangsblock (12) einen Ausgabewert (46) aufweist, der durch eine Verschlüsselung eines Basiswerts mit einem asymmetrischen Verschlüsselungsverfahren unter Verwendung eines Schlüssels von zwei unterschiedlichen Schlüsseln (P, Ö), die einen privaten (P) und einen öffentlichen (Ö) Schlüssel umfassen, erzeugt worden ist, wobei der Basiswert eine Verknüpfung eines Nutzdatenschlüssels, mit dem die verschlüsselten Nutzdaten unter Verwendung eines Nutzdaten-Verschlüsselungsalgorithmus verschlüsselt sind, mit durch eine bestimmte Verarbeitung abgeleiteten Informationen, die einen bestimmten Teil des Nutzdatenstroms (10) eindeutig kennzeichnen, darstellt, mit folgenden Schritten:
Erhalten (120) des Ausgabewerts (46) aus dem Anfangsblock (12);
Entschlüsseln (122) des Ausgabewerts (46) unter Verwendung des anderen Schlüssels des asymmetrischen Ver- Schlüsselungsverfahrens, um den Basiswert zu erhalten;
Verarbeiten (124) eines Teils des Nutzdatenstroms (10) —unter Verwendung des beim Verschlüsseln verwendeten Verarbeitungsverfahrens, um Informationen abzuleiten, die den Teil kennzeichnen, wobei der Teil dem bestimmten Teil beim Verschlüsseln entspricht;
Verknüpfen (126) der Informationen mit dem Basiswert unter Verwendung der entsprechenden Verknüpfung, wie sie beim Verschlüsseln verwendet wurde, um den Nutzdatenschlüssel zu erhalten; und
Entschlüsseln (128) des Blocks (14) mit verschlüsselten Nutzdaten unter Verwendung des Nutzdaten-Schlüssels und des beim Verschlüsseln verwendeten Nutzdaten-Verschlüsselungsalgorithmus .
18. Verfahren nach Anspruch 17, bei dem der Anfangsblock (12) Lizenzinformationen (30) aufweist, die sich darauf beziehen, in welcher Weise der Nutzdatenstrom (10) verwendet werden kann.
19. Verfahren nach Anspruch 17 oder 18, bei dem der Teil, der verarbeitet wird, um die Informationen abzuleiten, der Anfangsblock (12) ist.
20. Verfahren nach Anspruch 18 oder 19, das ferner folgenden Schritt aufweist:
Überprüfen, ob die Lizenzinformationen (30) ein Entschlüsseln erlauben; und
falls ein Entschlüsseln nicht erlaubt ist, Abbrechen des Entschlüsselungsverfahrens.
21. Verfahren nach einem der Ansprüche 17 bis 20, bei dem der Anfangsblock (12) einen Benutzereintrag (44) auf- weist, das ferner folgende Schritte aufweist:
Überprüfen, ob ein aktueller Benutzer autorisiert ist, —anhand des Benutzereintrags (44); und
falls der Benutzer nicht autorisiert ist, Abbrechen des Entschlüsselungsverfahrens .
22. Verfahren nach einem der Ansprüche 17 bis 21, bei dem der eine Schlüssel, der beim Verschlüsseln verwendet wurde, der private Schlüssel (P) des asymmetrischen Verschlüsselungsverfahrens ist, während der andere Schlüssel, der beim Entschlüsseln verwendet wird, der öffentliche Schlüssel (Ö) des asymmetrischen Verschlüsselungsverfahrens ist.
23. Verfahren nach einem der Ansprüche 17 bis 21, bei dem der eine Schlüssel, der beim Verschlüsseln verwendet wurde, der öffentliche Schlüssel (Ö) des asymmetrischen Verschlüsselungsverfahrens ist, während der andere Schlüssel, der beim Entschlüsseln verwendet wird, der private Schlüssel (P) des asymmetrischen Verschlüsselungsverfahrens ist.
24. Verfahren nach einem der Ansprüche 17 bis 23, bei dem der Schritt des Verarbeitens (124) das Bilden einer Hash-Summe umfaßt.
25. Verfahren nach einem der Ansprüche 17 bis 24, bei dem ein Teil des Anfangsblocks (12), der beim Verschlüsseln für den Schritt des Verarbeitens auf einen definierten Wert gesetzt wurde, beim Entschlüsseln für den Schritt des Verarbeitens (124) auf denselben definierten Wert gesetzt wird.
26. Verfahren nach Anspruch 25, bei dem der Teil des Anfangsblocks ( 12 ) , der auf einen definierten Wert gesetzt wird, den Eintrag für den Ausgabewert (46) des Anfangsblocks (12) umfaßt.
27. Verfahren nach einem der Ansprüche 17 bis 26, bei dem — der Schritt des Verknüpfens (126) das Verwenden einer
EXKLUSIV-ODER-Verknüpfung aufweist.
28. Vorrichtung zum Erzeugen eines verschlüsselten Nutzdatenstroms, der einen Anfangsblock (12) und einen Nutzdatenblock (14) mit verschlüsselten Nutzdaten aufweist, mit folgenden Merkmalen:
einer Einrichtung zum Generieren (102) eines Nutzdaten-Schlüssels für einen Nutzdaten-Verschlüsselungsalgorithmus zum Verschlüsseln von Nutzdaten;
einer Einrichtung zum Verschlüsseln (104) von Nutzdaten unter Verwendung des Nutzdaten-Schlüssels und des Nutzdaten-Verschlüsselungsalgorithmus, um einen verschlüsselten Abschnitt (16) des Nutzdatenblocks (14) des Nutzdatenstroms (10) zu erhalten;
einer Einrichtung zum Verarbeiten (106) eines Teils des Nutzdatenstroms (10), um Informationen abzuleiten, die den Teil des Nutzdatenstroms kennzeichnen;
einer Einrichtung zum Verknüpfen (108) der Informationen mit dem Nutzdatenschlüssels mittels einer invertierbaren logischen Verknüpfung, um einen Basiswert zu erhalten;
einer Einrichtung zum Verschlüsseln (110) des Basiswerts unter Verwendung eines Schlüssels von zwei zueinander unterschiedlichen Schlüsseln (P, Ö) mit einem asymmetrischen Verschlüsselungsverfahren, wobei die zwei unterschiedlichen Schlüssel der öffentliche (Ö) bzw. der private (P) Schlüssel für das asymmetrische Verschlüsselungsverfahren sind, um einen Ausgabewert (46) zu erhalten, der eine verschlüsselte Version des Nutzdatenschlüssels ist; und
einer Einrichtung zum Eintragen (112) des Ausgabewerts —(46) in den Anfangsblock (12) des Nutzdatenstroms (10).
29. Vorrichtung zum Entschlüsseln eines verschlüsselten Nutzdatenstroms (10), der einen Anfangsblock (12) und einen Block (14) mit verschlüsselten Nutzdaten aufweist, wobei der Anfangsblock (12) einen Ausgabewert (46) aufweist, der durch eine Verschlüsselung eines Basiswerts mit einem asymmetrischen Verschlüsselungsverfahren unter Verwendung eines Schlüssels von zwei unterschiedlichen Schlüsseln (P, Ö), die einen privaten (P) und einen öffentlichen (Ö) Schlüssel umfassen, erzeugt worden ist, wobei der Basiswert eine Verknüpfung eines Nutzdatenschlüssels, mit dem die verschlüsselten Nutzdaten unter Verwendung eines Nutzdaten-Verschlüsselungsalgorithmus verschlüsselt sind, von durch eine bestimmte Verarbeitung abgeleiteten Informationen, die einen bestimmten Teil des Nutzdatenstroms (10) eindeutig kennzeichnen, darstellt, mit folgenden Merkmalen:
einer Einrichtung zum Erhalten (120) des Ausgabewerts (46) aus dem Anfangsblock (12);
einer Einrichtung zum Entschlüsseln (122) des Ausgabewerts (46) unter Verwendung des anderen Schlüssels (Ö) und des asymmetrischen Verschlüsselungsverfahrens, um den Basiswert zu erhalten;
einer Einrichtung zum Verarbeiten (124) eines Teils des Nutzdatenstroms (10) unter Verwendung des beim Verschlüsseln verwendeten Verarbeitungsverfahrens, um Informationen abzuleiten, die den Teil kennzeichnen, wobei der Teil dem bestimmten Teil beim Verschlüsseln entspricht;
einer Einrichtung zum Verknüpfen (126) der Informatio- nen mit dem Basiswert unter Verwendung der entsprechenden Verknüpfung, wie sie beim Verschlüsseln verwendet wurde, um den Nutzdatenschlüssel zu erhalten; und
einer Einrichtung zum Entschlüsseln (128) des Blocks (14) mit verschlüsselten Nutzdaten unter Verwendung des Nutzdaten-Schlüssels und des beim Verschlüsseln verwendeten Nutzdaten-Verschlüsselungsalgorithmus .
30. Vorrichtung nach Anspruch 28 oder 29, die als Personalcomputer, als Stereoanlage, als Auto-HiFi-Gerät, als Solid-State-Player oder als Abspielgerät mit Festplatte oder CD-ROM ausgeführt ist.
EP99965472A 1999-02-16 1999-12-15 Verfahren und vorrichtung zum erzeugen eines verschlüsselten nutzdatenstroms und verfahren und vorrichtung zum entschlüsseln eines verschlüsselten nutzdatenstroms Expired - Lifetime EP1133849B1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE19906450A DE19906450C1 (de) 1999-02-16 1999-02-16 Verfahren und Vorrichtung zum Erzeugen eines verschlüsselten Nutzdatenstroms und Verfahren und Vorrichtung zum Entschlüsseln eines verschlüsselten Nutzdatenstroms
DE19906450 1999-02-16
PCT/EP1999/009981 WO2000049763A1 (de) 1999-02-16 1999-12-15 Verfahren und vorrichtung zum erzeugen eines verschlüsselten nutzdatenstroms und verfahren und vorrichtung zum entschlüsseln eines verschlüsselten nutzdatenstroms

Publications (2)

Publication Number Publication Date
EP1133849A1 true EP1133849A1 (de) 2001-09-19
EP1133849B1 EP1133849B1 (de) 2002-06-12

Family

ID=7897679

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99965472A Expired - Lifetime EP1133849B1 (de) 1999-02-16 1999-12-15 Verfahren und vorrichtung zum erzeugen eines verschlüsselten nutzdatenstroms und verfahren und vorrichtung zum entschlüsseln eines verschlüsselten nutzdatenstroms

Country Status (6)

Country Link
US (1) US7434052B1 (de)
EP (1) EP1133849B1 (de)
JP (1) JP4263370B2 (de)
AT (1) ATE219311T1 (de)
DE (2) DE19906450C1 (de)
WO (1) WO2000049763A1 (de)

Families Citing this family (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060143252A1 (en) * 2000-03-09 2006-06-29 Pkware, Inc. System and method for manipulating and managing computer archive files
US8959582B2 (en) 2000-03-09 2015-02-17 Pkware, Inc. System and method for manipulating and managing computer archive files
US8230482B2 (en) * 2000-03-09 2012-07-24 Pkware, Inc. System and method for manipulating and managing computer archive files
US20050015608A1 (en) 2003-07-16 2005-01-20 Pkware, Inc. Method for strongly encrypting .ZIP files
US7844579B2 (en) 2000-03-09 2010-11-30 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060155731A1 (en) * 2000-03-09 2006-07-13 Pkware, Inc. System and method for manipulating and managing computer archive files
US6879988B2 (en) 2000-03-09 2005-04-12 Pkware System and method for manipulating and managing computer archive files
US20060143250A1 (en) * 2000-03-09 2006-06-29 Pkware, Inc. System and method for manipulating and managing computer archive files
US20060143714A1 (en) * 2000-03-09 2006-06-29 Pkware, Inc. System and method for manipulating and managing computer archive files
US6766376B2 (en) 2000-09-12 2004-07-20 Sn Acquisition, L.L.C Streaming media buffering system
DE10059230C2 (de) * 2000-11-29 2002-11-28 4Friendsonly Com Internet Tech Verfahren zur Verfügbarmachung von multimedialen Datenmengen
GB0116713D0 (en) * 2001-07-09 2001-08-29 Amino Holdings Ltd Variable security encryption method and apparatus
JP3925218B2 (ja) * 2002-01-30 2007-06-06 ソニー株式会社 ストリーミングシステム及びストリーミング方法、ストリーミングサーバ及びデータ配信方法、クライアント端末及びデータ復号方法、並びにプログラム及び記録媒体
US7356147B2 (en) * 2002-04-18 2008-04-08 International Business Machines Corporation Method, system and program product for attaching a title key to encrypted content for synchronized transmission to a recipient
WO2004086664A2 (en) * 2003-03-27 2004-10-07 Nds Limited Improved cfm mode system
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
JP4749680B2 (ja) * 2004-05-10 2011-08-17 株式会社ソニー・コンピュータエンタテインメント データ構造、データ処理装置、データ処理方法、認証装置、認証方法、コンピュータプログラム、及び記録媒体
US9219729B2 (en) 2004-05-19 2015-12-22 Philip Drope Multimedia network system with content importation, content exportation, and integrated content management
DE102004052101B4 (de) * 2004-10-26 2009-01-15 Comvenient Gmbh & Co. Kg Verfahren und Vorrichtung zur Entschlüsselung breitbandiger Daten
EP2579497A1 (de) 2005-05-02 2013-04-10 Nds Limited Natives scrambling-system
US7684566B2 (en) * 2005-05-27 2010-03-23 Microsoft Corporation Encryption scheme for streamed multimedia content protected by rights management system
US8321690B2 (en) 2005-08-11 2012-11-27 Microsoft Corporation Protecting digital media of various content types
US7831789B1 (en) * 2005-10-06 2010-11-09 Acronis Inc. Method and system for fast incremental backup using comparison of descriptors
US8978154B2 (en) * 2006-02-15 2015-03-10 Samsung Electronics Co., Ltd. Method and apparatus for importing content having plurality of parts
KR100782847B1 (ko) * 2006-02-15 2007-12-06 삼성전자주식회사 복수의 컨텐트 부분들을 포함하는 컨텐트를 임포트하는방법 및 장치
KR100846787B1 (ko) 2006-02-15 2008-07-16 삼성전자주식회사 트랜스포트 스트림을 임포트하는 방법 및 장치
US7515710B2 (en) 2006-03-14 2009-04-07 Divx, Inc. Federated digital rights management scheme including trusted systems
US8583929B2 (en) * 2006-05-26 2013-11-12 Alcatel Lucent Encryption method for secure packet transmission
EP3901779B1 (de) 2007-01-05 2022-10-26 DivX, LLC Videoverteilungssystem mit progressiver wiedergabe
KR101478173B1 (ko) 2007-08-29 2014-12-31 삼성전자주식회사 외부기기 연결 방법 및 이를 적용한 멀티미디어 재생장치
US7961878B2 (en) 2007-10-15 2011-06-14 Adobe Systems Incorporated Imparting cryptographic information in network communications
EP2223232A4 (de) 2007-11-16 2015-02-25 Sonic Ip Inc Hierarchische und reduzierte indexstrukturen für multimediadateien
US20100312810A1 (en) * 2009-06-09 2010-12-09 Christopher Horton Secure identification of music files
JP5723888B2 (ja) 2009-12-04 2015-05-27 ソニック アイピー， インコーポレイテッド 基本ビットストリーム暗号材料伝送システムおよび方法
US9247312B2 (en) 2011-01-05 2016-01-26 Sonic Ip, Inc. Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol
EP2518448A1 (de) * 2011-04-27 2012-10-31 Nagravision S.A. System zur Optimierung der vorgeschalteten Stromzählerkommunikationen und Verfahren zur Verwaltung dieser Kommunikationen
US8812662B2 (en) 2011-06-29 2014-08-19 Sonic Ip, Inc. Systems and methods for estimating available bandwidth and performing initial stream selection when streaming content
KR101857791B1 (ko) * 2011-08-30 2018-05-16 삼성전자주식회사 컴퓨팅 시스템, 및 상기 컴퓨팅 시스템을 동작하기 위한 방법
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
KR101928910B1 (ko) 2011-08-30 2018-12-14 쏘닉 아이피, 아이엔씨. 복수의 최대 비트레이트 레벨들을 사용하여 인코딩된 비디오를 인코딩하고 스트리밍하기 위한 시스템들 및 방법들
US8799647B2 (en) 2011-08-31 2014-08-05 Sonic Ip, Inc. Systems and methods for application identification
US8787570B2 (en) 2011-08-31 2014-07-22 Sonic Ip, Inc. Systems and methods for automatically genenrating top level index files
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
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US20130179199A1 (en) 2012-01-06 2013-07-11 Rovi Corp. Systems and methods for granting access to digital content using electronic tickets and ticket tokens
US9088805B2 (en) * 2012-02-08 2015-07-21 Vixs Systems, Inc. Encrypted memory device and methods for use therewith
US9936267B2 (en) 2012-08-31 2018-04-03 Divx Cf Holdings Llc System and method for decreasing an initial buffering period of an adaptive streaming system
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
EP2962422B1 (de) 2013-02-27 2020-09-23 Ciphertooth, Inc. Verfahren und vorrichtung zur sicheren datenübertragung
US10182041B2 (en) 2013-02-27 2019-01-15 CipherTooth, Inc. Method and apparatus for secure data transmissions
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
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9100687B2 (en) 2013-05-31 2015-08-04 Sonic Ip, Inc. Playback synchronization across playback devices
US9380099B2 (en) 2013-05-31 2016-06-28 Sonic Ip, Inc. Synchronizing multiple over the top streaming clients
US9794230B2 (en) * 2013-07-20 2017-10-17 Ittiam Systems (P) Ltd. Method and system for encrypting multimedia streams
US9386067B2 (en) 2013-12-30 2016-07-05 Sonic Ip, Inc. Systems and methods for playing adaptive bitrate streaming content by multicast
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
KR102597985B1 (ko) 2014-08-07 2023-11-06 디빅스, 엘엘씨 독립적으로 인코딩된 타일을 포함한 기본 비트스트림을 보호하는 시스템 및 방법
EP3910904A1 (de) 2015-01-06 2021-11-17 DivX, LLC Systeme und verfahren zur codierung und gemeinsamen nutzung von inhalten zwischen vorrichtungen
US10715574B2 (en) 2015-02-27 2020-07-14 Divx, Llc Systems and methods for frame duplication and frame extension in live video encoding and streaming
US10075292B2 (en) 2016-03-30 2018-09-11 Divx, Llc Systems and methods for quick start-up of playback
US10231001B2 (en) 2016-05-24 2019-03-12 Divx, Llc Systems and methods for providing audio content during trick-play playback
US10129574B2 (en) 2016-05-24 2018-11-13 Divx, Llc Systems and methods for providing variable speeds in a trick-play mode
US10148989B2 (en) 2016-06-15 2018-12-04 Divx, Llc Systems and methods for encoding video content
JP7076819B2 (ja) * 2016-09-15 2022-05-30 ナッツ・ホールディングス、エルエルシー 暗号化されたユーザデータの移動および記憶
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
US10291594B2 (en) * 2017-08-31 2019-05-14 Fmr Llc Systems and methods for data encryption and decryption
US20190246148A1 (en) * 2018-02-05 2019-08-08 Digicap Co., Ltd. Method and system for scrambling broadcast with low latency
WO2020191406A1 (en) 2019-03-21 2020-09-24 Divx, Llc Systems and methods for multimedia swarms
IL296952A (en) 2020-04-09 2022-12-01 Nuts Holdings Llc (Encrypted User Data Transit and Storage Policy): Flexible Hierarchy Object Graphs

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4965825A (en) * 1981-11-03 1990-10-23 The Personalized Mass Media Corporation Signal processing apparatus and methods
US4899333A (en) * 1988-03-31 1990-02-06 American Telephone And Telegraph Company At&T Bell Laboratories Architecture of the control of a high performance packet switching distribution network
JPH03214834A (ja) * 1990-01-19 1991-09-20 Canon Inc マルチメデイアネツトワークシステム
US5200999A (en) * 1991-09-27 1993-04-06 International Business Machines Corporation Public key cryptosystem key management based on control vectors
US5315635A (en) * 1992-09-30 1994-05-24 Motorola, Inc. Reliable message communication system
CN100501754C (zh) 1995-02-13 2009-06-17 英特特拉斯特技术公司 用于安全交易管理和电子权利保护的系统和方法
US6526509B1 (en) * 1995-05-19 2003-02-25 Siemens Aktiengesellschaft Method for interchange of cryptographic codes between a first computer unit and a second computer unit
US6175626B1 (en) * 1995-09-29 2001-01-16 Intel Corporation Digital certificates containing multimedia data extensions
US5712914A (en) * 1995-09-29 1998-01-27 Intel Corporation Digital certificates containing multimedia data extensions
DE19625635C1 (de) * 1996-06-26 1997-12-04 Fraunhofer Ges Forschung Verschlüsselung und Entschlüsselung von Multimediadaten
US5710814A (en) * 1996-07-23 1998-01-20 Cheyenne Property Trust Cryptographic unit touch point logic
US5850443A (en) * 1996-08-15 1998-12-15 Entrust Technologies, Ltd. Key management system for mixed-trust environments
JPH10107787A (ja) 1996-09-27 1998-04-24 Mitsubishi Corp データ管理システム
US5805700A (en) * 1996-10-15 1998-09-08 Intel Corporation Policy based selective encryption of compressed video data
US6198875B1 (en) * 1996-12-20 2001-03-06 Texas Instruments Incorporated Tiris based bios for protection of “copyrighted” program material
EP0978965B1 (de) * 1997-04-24 2006-05-03 Matsushita Electric Industrial Co., Ltd. Datentransferverfahren
JP3595109B2 (ja) * 1997-05-28 2004-12-02 日本ユニシス株式会社 認証装置、端末装置、および、それら装置における認証方法、並びに、記憶媒体
US6738907B1 (en) * 1998-01-20 2004-05-18 Novell, Inc. Maintaining a soft-token private key store in a distributed environment
KR100611867B1 (ko) * 1998-01-26 2006-08-11 마츠시타 덴끼 산교 가부시키가이샤 데이터 기록재생방법, 데이터 기록재생 시스템, 기록장치, 재생장치, 프로그램 기록매체
US5974144A (en) * 1998-02-25 1999-10-26 Cipheractive Ltd. System for encryption of partitioned data blocks utilizing public key methods and random numbers
DE69824975T2 (de) * 1998-07-13 2005-08-25 International Business Machines Corp. Verfahren zur übertragung von informationsdaten von einem sender zu einem empfänger über einen transcoder
KR100484209B1 (ko) * 1998-09-24 2005-09-30 삼성전자주식회사 디지털컨텐트암호화/해독화장치및그방법
JP4427693B2 (ja) * 1998-10-02 2010-03-10 ソニー株式会社 データ処理装置および方法、並びにデータ復号処理装置および方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0049763A1 *

Also Published As

Publication number Publication date
ATE219311T1 (de) 2002-06-15
EP1133849B1 (de) 2002-06-12
WO2000049763A1 (de) 2000-08-24
US7434052B1 (en) 2008-10-07
DE59901773D1 (de) 2002-07-18
JP4263370B2 (ja) 2009-05-13
DE19906450C1 (de) 2000-08-17
JP2002537724A (ja) 2002-11-05

Similar Documents

Publication Publication Date Title
EP1133849B1 (de) Verfahren und vorrichtung zum erzeugen eines verschlüsselten nutzdatenstroms und verfahren und vorrichtung zum entschlüsseln eines verschlüsselten nutzdatenstroms
EP1151561B1 (de) Verfahren und vorrichtung zum erzeugen eines datenstroms und verfahren und vorrichtung zum abspielen eines datenstroms
EP1151610B1 (de) Verfahren und vorrichtung zum erzeugen eines verschlüsselten nutzdatenstroms und verfahren und vorrichtung zum abspielen eines verschlüsselten nutzdatenstroms
DE69836450T2 (de) Verschlüsselungs-, Entschlüsselungs- und Informationsverarbeitungsgerät und -verfahren
DE19625635C1 (de) Verschlüsselung und Entschlüsselung von Multimediadaten
DE60016972T2 (de) Anpassbarer sicherheitsmechanismus, um unerlaubten zugang zu digitalen daten zu verhindern
EP2067339B1 (de) Vorrichtung und Verfahren zur gesicherten Verteilung von Inhalten in einem Telekommunikationsnetzwerk
DE69719803T3 (de) Verhinderung von wiedergabeangriffen auf durch netzwerkdiensteanbieter verteilte digitale informationen
DE69833608T2 (de) Informationsübertragung,-empfang und -aufzeichnung
DE602004005485T2 (de) Verfahren zum beurteilen der nutzungserlaubnis für informationen und inhaltsverbreitungssystem, das dieses verfahren verwendet
DE60126874T2 (de) Vorrichtung und verfahren zur informationsverarbeitung
DE112007002566B4 (de) Verfahren zum Übertragen eines Datenobjekts zwischen Vorrichtungen, und Vorrichtung zum Durchsetzen eines Protokolls
EP1300842B1 (de) Verfahren und System zur autorisierten Entschlüsselung von verschlüsselten Daten mit mindestens zwei Zertifikaten
EP1184771B1 (de) Verfahren zum Schutz von Computer-Software und/oder computerlesbaren Daten sowie Schutzgerät
DE19529487C2 (de) System zur gebührenpflichtigen Abgabe von Software
DE60114069T2 (de) System und Verfahren für den Schutz von Digitalwerken
DE69910786T2 (de) Verfahren zur Verteilung von Schlüsseln an eine Anzahl gesicherter Geräten, Verfahren zur Kommunikation zwischen einer Anzahl gesicherter Geräten, Sicherheitssystem, und Satz gesicherter Geräten
DE60318633T2 (de) Verwaltung digitaler rechte
DE69836215T2 (de) System um verschlüsselte Daten zu liefern, System um verschlüsselte Daten zu entschlüsseln und Verfahren um eine Kommunikationsschnittstelle in einem solchen System zur Verfügung zu stellen
DE60024768T2 (de) Aktualisierung einer sperrliste um einem widersacher entgegenzuarbeiten
DE102004010853B4 (de) Verfahren und Vorrichtung zum Abspielen eines Inhalts
DE10220925B4 (de) Vorrichtung und Verfahren zum Erzeugen von verschlüsselten Daten, zum Entschlüsseln von verschlüsselten Daten und zum Erzeugen von umsignierten Daten
EP2184695A1 (de) Verfahren zum Kombinieren von Daten mit einer zur Verarbeitung der Daten vorgesehenen Vorrichtung, korrespondierende Funktionalität zur Ausführung einzelner Schritte des Verfahrens und Computerprogram zur Implementierung des Verfahrens
DE60012351T2 (de) System und verfahren zum überprüfen der berechtigung zur übertragung geschützten informationsinhalts
WO2007113163A1 (de) Verbessertes digitales rechtemanagement für gruppen von geräten

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20010713

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAG Despatch of communication of intention to grant

Free format text: ORIGINAL CODE: EPIDOS AGRA

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

17Q First examination report despatched

Effective date: 20011121

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT CH DE GB LI

REF Corresponds to:

Ref document number: 219311

Country of ref document: AT

Date of ref document: 20020615

Kind code of ref document: T

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REF Corresponds to:

Ref document number: 59901773

Country of ref document: DE

Date of ref document: 20020718

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: GERMAN

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

Ref document number: 1133849E

Country of ref document: IE

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20030313

REG Reference to a national code

Ref country code: CH

Ref legal event code: PFA

Owner name: FRAUNHOFER-GESELLSCHAFT ZUR FOERDERUNG DER ANGEWA

Free format text: FRAUNHOFER-GESELLSCHAFT ZUR FOERDERUNG DER ANGEWANDTEN FORSCHUNG E.V.#LEONRODSTRASSE 54#80636 MUENCHEN (DE) -TRANSFER TO- FRAUNHOFER-GESELLSCHAFT ZUR FOERDERUNG DER ANGEWANDTEN FORSCHUNG E.V.#HANSASTRASSE 27 C#80686 MUENCHEN (DE)

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: AT

Payment date: 20181213

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20181219

Year of fee payment: 20

Ref country code: CH

Payment date: 20181219

Year of fee payment: 20

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20181220

Year of fee payment: 20

REG Reference to a national code

Ref country code: DE

Ref legal event code: R071

Ref document number: 59901773

Country of ref document: DE

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

REG Reference to a national code

Ref country code: GB

Ref legal event code: PE20

Expiry date: 20191214

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20191214

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK07

Ref document number: 219311

Country of ref document: AT

Kind code of ref document: T

Effective date: 20191215