HK1066675B

HK1066675B - Digital content distribution system

Info

Publication number: HK1066675B
Application number: HK04109480.4A
Authority: HK
Inventors: 伊凡．H．迈克莱恩; 安德鲁．A．瓦伊斯
Original assignee: 耶德托存取公司
Priority date: 2001-12-19
Filing date: 2002-12-18
Publication date: 2009-09-04

Description

Digital content distribution system

Background

The present invention relates to cryptographic protocols for performing, for example, efficient content level encryption (e.g., encrypting an MPEG-4 bitstream).

In particular, the invention relates to a method of generating cryptographically protected digital data encoding content and configured into messages, each message being decodable by a decoder application on a client terminal having a service interface provided with each message for the decoder application, the method comprising the steps of:

retrieving a message from a machine-readable medium;

encrypting at least a portion of the message; and

providing as output the encrypted message in a format that enables a server service interface to arrange the message in at least one packet that includes at least one header and a payload, each payload including at least part of the message, the at least one header including information that enables a service interface on the client to assemble each message for the decoder application from the payload of the packet.

The invention also relates to a server capable of decrypting cryptographically protected data generated by a method of encoding and configuring content into messages.

The invention also relates to a system for generating cryptographically protected digital data encoding and configuring content into messages, each message being decodable by a decoder application on a client terminal having a service interface provided for each message of the decoder application, said system being configured to:

retrieving a message from a machine-readable medium;

encrypting at least a portion of the message; and

providing as output the encrypted message in a format that enables a server service interface to arrange the message in at least one packet that each includes at least one header and a payload, each payload including at least part of the message, the at least one header including information that enables the service interface on the client to assemble each message for the decoder application from the payload of the packet.

The invention also relates to a method of distributing digital data encoding and configuring content into messages from a server to one or more client terminals over a network, each message being decodable by a decoder application on a client terminal, the method comprising:

transmitting a plurality of data packets from the server through the network interface of the server and a network, each packet comprising at least a header and a payload, each payload comprising a portion of at least one message;

providing each message to a first service interface of a series of service interfaces installed on said server having at least one service interface between two layers in a protocol stack, each service interface being configured to add at least one packet header to packet encoding information enabling the client to process the remainder of the packet, said method further comprising transmitting packets comprising at least one header including information enabling a service interface on the client to assemble each message derived from the payload of those packets by a decoder application.

The invention also relates to a server for distributing digital data encoding and configuring content into messages to one or more client terminals over a network, each message being decodable by a decoder application on a client terminal, said server comprising:

a network interface for transmitting a plurality of data packets from a server over a network, each packet comprising at least a header and a payload, each payload comprising a portion of at least one message, the server further comprising a series of service interfaces having at least one service interface between two layers within a protocol stack, each service interface being configured to add at least one packet header to packet encoding information enabling a client to process the remainder of the packet, the server being configured to transmit packets comprising at least one header including information enabling a service interface on a client to assemble a decoder application for each message derived from the payload of the packets.

The invention also relates to a client terminal for receiving and processing digital data encoding and configuring content into messages, each message being decodable by a decoder application, said client terminal comprising:

an interface for receiving a plurality of data packets, each packet comprising at least a header and a payload, the terminal further comprising a series of service interfaces having at least one service interface between two layers in a protocol stack, each service interface being configured to remove at least one packet header from a packet and to process the remainder of the packet with information encoded in the removed packet header, comprising a service interface configured to assemble a message derived from the payload of at least one packet by a decoder application with information included in at least one header of the packet.

The invention also relates to a method of receiving and processing digital data encoding and arranging content into messages in a client terminal, each message being decodable by a decoder application, said method comprising:

receiving a plurality of data packets via an interface of the client terminal, each packet comprising at least a header and a payload;

each packet is provided to a first service interface of a series of service interfaces having at least one service interface between two layers within a protocol stack, each service interface being configured to remove at least one packet header from the packet and process the remainder of the packet with information encoded within the removed packet header, including a service interface configured to assemble a message derived from a payload of the at least one packet by a decoder application with information included within the at least one header of the packet.

The invention also relates to a computer program loadable into a computer and operable on the computer to provide the functionality of such a system, server or client terminal for a computer.

The invention finally relates to a computer program which can be loaded into a computer and which, when running on the computer, can cause the computer to carry out one of the methods described above.

Some examples of such systems and methods can be seen from, for example, the international standard ISO/IEC 14496-1 known as MPEG (moving Picture experts group) -4.

MPEG and MPEG-4 are standards that have been proposed, widely used in the case of MPEG for distributing video and to a lesser extent for other forms of content. In addition, applications such as distribution of digital content over the internet, etc., have caused a requirement for encryption of content, whether in MPEG, MPEG-4, or any other format.

The MPEG-4 standard specifies an architecture in which elementary streams of streaming data are formed from a scene description and transmitted into basic building blocks. To distribute streaming data, the transmission takes place within some SL Packetized Stream (SPS). The packets contain elementary stream data divided by access units and side information, e.g. for timing and marking the access units. The timing model depends on a clock reference and time stamps that synchronize the audio-visual data conveyed by the one or more elementary streams. The concept of a clock and the clock reference associated with it are used to convey the concept of time to the receiving terminal. The time stamp is used to indicate the exact moment the receiving terminal uses the access unit in the decoding buffer. The Object Time Base (OTB) defines the notion of time for a given data stream. The resolution of this OTB can be selected according to the application needs or as defined by an overview. All time stamps inserted into an encoded data stream by the transmitting end are referenced to this time base. The OTB of a data stream is known at the receiving terminal by means of an Object Clock Reference (OCR) time stamp in the SL packet header of the stream or by an indication of the elementary stream from which the object descriptor stream inherits the time base.

The object description framework includes a set of descriptors that identify, describe, and correctly correlate elementary streams with each other and with the audiovisual objects used in the scene description. An object descriptor is a collection of descriptors that describe one or more elementary streams associated with a single node within the scene. An elementary stream descriptor within an object descriptor identifies an individual elementary stream. Each elementary stream descriptor contains the necessary information to initialize and configure the decoding process of the elementary stream and an identification of intellectual property rights. Intellectual Property Management and Protection (IPMP) information is transported via IPMP descriptors as part of the object descriptor stream and via IPMP streams (elementary streams carrying time-varying IPMP information, in particular content encryption keys). The key is associated with the content or other stream by an appropriate IPMP stream descriptor. These keys must be synchronized with the content stream. The existing MPEG-4 model is used for delay and synchronization management. Therefore, the decryption application within the receiving terminal must properly manage the time stamps.

The MPEG-4 bitstream syntax, in its current form, does not provide explicit support for resynchronization of the decryption process in case some parts of the encrypted content bitstream are lost during transmission. Since MPEG-4 does not specify a transport layer, it is impossible to apply the characteristics of the basic transport protocol for synchronization. MPEG-4 media can also be played back locally, in which case there is no transport involved. In error-prone environments, losing a single bit can actually corrupt the rest of the frame. There are many passwords and associated modes that cannot perform self-synchronization, but are very attractive under many ratings criteria. Currently, these must be excluded simply because there is no sync extension to support the decryption process in case of data loss.

Summary of The Invention

The present invention provides a method and system for generating password-protected digital data encoding contents and distributing the digital data, and a client terminal and method for receiving and processing the digital data, thereby realizing a data distribution system in which contents are sufficiently protected against unauthorized access and error recovery are improved.

The present invention achieves this object by providing a method of generating cryptographically protected digital data encoding content and configured into messages, each message being encoded so that it can be decoded by a decoder application at a client terminal having a service interface for assembling each message for the decoder application, the method comprising the steps of:

retrieving a message from a machine-readable medium;

encrypting at least a portion of the message; and

providing as output encrypted messages in a format enabling a server service interface to configure the messages into at least one packet comprising at least one header and a payload, each payload comprising at least a portion of the message, the at least one header comprising information enabling the service interface at the client to assemble each message for decoder applications from the payload of the packets, wherein the method comprises separating each message into a first message segment and at least one further message segment, wherein the at least one message segment is encrypted in such a way that it decrypts each encrypted message segment independently of the other message segments, and wherein the encrypted messages are assembled by adding to at least the further message segment a resynchronization marker comprising explicit synchronization information separating an encrypted message segment from an adjacent message segment.

One message is a unit of data sent from an encoder program that encodes the content to a decoder application on the client that is configured to process the respective message to decode the content. The content may be, for example, video, audio or text. A service interface is a part of a protocol that implements a protocol in a protocol stack, providing a communication service where applications at one layer of the protocol stack can exchange information using the functionality of the protocol at a different layer of the protocol stack. Preferably, this is a network protocol stack, for example complying with the OSI network architecture. However, the service interface may also provide an interface between the application and the operating system of the system, such as converting messages into file system defined packets of the operating system. By "independently decrypt," it is meant that each encrypted message segment can be decrypted without knowledge of the ciphertext or plaintext of another message segment. Within the context of this application, a header is a piece of data preceding or following the payload of a packet that encodes information that will describe certain circumstances about the packet or its payload. A packet is a self-contained, independent entity that carries sufficient information to be transmitted from a source to a sink (destination) independent of previous exchanges between the source and the sink and the interface between them.

Since each message segment is independently decryptable, and since the resynchronization marker provides an explicit indication of the boundary between adjacent encrypted message segments, errors or data loss within one segment do not affect the client's ability to decrypt other message segments. That is, the lack of all or a portion of the previous data blocks in the client does not affect the ability to decrypt the current data block. By adjusting the length of the message segments, i.e. the number of resynchronization marks, more or less flexibility can be provided. Furthermore, only a few segments of a message can be encrypted, which reduces the decryption processing time and the requirements on the client capabilities.

It should be noted that the MPEG-4 bitstream syntax defines a resynchronization marker (ResyncMarker). The resynchronization marker provides better error recovery by increasing the chances of resynchronization between the decoder and the bitstream after a residual error is detected. Typically, data between the synchronization point before the error and the point at which resynchronization is established is discarded. These markers are guaranteed to be unique to the unencrypted MPEG-4 active content. Although this structure is suitable for plaintext contents, it is not suitable for contents that are encrypted after being encoded. This appears to be the case whether selective encryption or brute force encryption is used on the entire message. This is so because although valid plaintext content cannot compete with a resynchronization mark (as would not be the case with a resynchronization mark), it is not applicable to encrypted data. More importantly, the MPEG-4 standard does not disclose encrypting at least one message segment to be decryptable independently of other message segments, and therefore requires, in the event of data loss, the reconstruction of the complete message by complex and often inappropriate error correction techniques for decryption by the client.

In a preferred embodiment of the invention, the message segment is encrypted with at least one key having a round value.

Thus, an improved security of the cryptographic analysis of the distributed content is provided.

Preferably, each resynchronization mark further comprises a unique serial number.

The use of sequence numbers involves all the issues surrounding allowing random access to encrypted media streams. It provides a cryptographic framework that enables a round-robin session key to be synchronized with associated media without imposing state dependencies on the sender or receiver within the content distribution system.

The MPEG-4 bitstream syntax, in its current form, does not provide explicit support for resynchronization of the decryption process in the event that the user performs a random view of the encrypted content bitstream. At the content level, MPEG-4 does not specify any reliable continuation or sequence information that can be relied upon during decryption. Using sync layer information is problematic because traditionally all SL information is deleted before decryption. Keeping SL information delivered to the IPMP tool presents a significant obstacle for most terminal implementations. The timing information cannot be used for synchronization because the DTS/CTS may change from the time the content is obtained to the time the content is used.

Traditionally, media formats have used explicit order information and/or consistent packet lengths to facilitate the encryption/decryption process. MPEG-4 media can also be played back locally, in which case there is no transport involved. Even if a well-defined mapping to transport layer order information can be specified, this is not helpful, since this information is not known at the time of obtaining the media.

The use of a unique sequence number allows efficient management of transitions during key cycling. A sequence number allows packaging and delivery of content from a media server while independently delivering keys from the server in a reliable manner, such as media carried on MPEG-2 or IPMP carried on an IF (internet protocol) network prior to storage on a DVD/CD-ROM. The presence of unique sequence information also allows the entire keystream to be transmitted before any media is transmitted.

Although the MPFG-4IPMP message stream provides the ability to deliver round robin session keys in-band, the MPEG-4 standard does not provide a reliable mechanism for delivering a new key that may be associated with a particular media access unit.

Media time (DTS/CTS) cannot be used for this purpose, since this can be changed from the time of obtaining the content to the time of using the content.

Furthermore, media streams and IPMP message streams carrying decryption keys may suffer from very different transport jitter, packet loss or network congestion, and tight synchronization with timestamps is almost impossible to achieve if IPMP message streams are sent from a different server to the client. Since there is no correlation between the media payload and the key, the delay of one IPMP AU can result in decryption with an incorrect key. Even a loss of synchronization of only one frame per key cycle is completely unacceptable.

A preferred embodiment of the method according to the invention further comprises adding an encapsulator (wrapper) encapsulating each encrypted message and containing a unique sequence number.

An encapsulator is data that is positioned before or after a message, provides information about the message, and can encapsulate the message from the perspective of anyone other than the intended recipient. An encapsulator can include a header preceding the encapsulated data and/or a trailer following it.

By using an encapsulator with a unique sequence number, the sequence information is also attributed to the first message segment within the message, thereby eliminating the need to have a resynchronization marker with explicit synchronization information.

Preferably, each unique serial number is provided in a self-describing format.

Thus, the sequence numbers may have variable lengths, reducing the added data.

A preferred embodiment of the method according to the invention further comprises generating at least one key message, each key message carrying data linking at least one unique sequence number added to a message with a key value enabling decryption of at least parts of the message.

This information can be used to associate the key data with any granularity of access unit data, regardless of the receiving terminal clock resolution.

An advantageous embodiment of the method according to the invention further comprises encrypting the message segments in the fed back cipher mode by using a cipher which is reinitialized at the beginning of each message segment.

Using feedback also known as linking provides additional security. It ensures that identical plaintext blocks are not encrypted into identical ciphertext blocks. It also provides protection against block replay cracking. By re-initializing the cipher at the beginning of each message segment, it is ensured that each encrypted message segment can be independently decrypted. More than one message can be encrypted with the same product or session key without sacrificing any security. Explicit or implicit IVs may be assumed to be used to avoid deep use of passwords.

Schneier, b. describes several cryptosystems in "Applied Cryptography", which successfully consider the problem of random access to varying degrees. Passwords and modes that work in a non-linked mode meet the criteria of not adding overhead or performing poorly in a lossy environment. For current encryption applications, electronic codebook mode (ECS) has some disadvantages because the data mode is not hidden (the same ciphertext block means the same plaintext block).

In a preferred variant of the last-mentioned embodiment, a unique sequence number within a resynchronization mark separating a further message segment from another message segment is used as initialization vector for encrypting the further message segment.

Thus, the decryption process can be synchronized in the event of data loss or random viewing of the media.

Techniques such as ECB + OFB (electronic codebook mode + output feedback mode) and CBC (cipher block chaining) that produce implicit IVs do not perform well in lossy environments, either by increasing overhead. Generating an implicit IV (initialization vector) based on some characteristics of the message seems problematic because a bit error or data loss of the IV data can result in the scrambling of all plaintext. There are many encryption and associated modes that cannot perform self-synchronization, but are very attractive under many ratings standards. Currently, these modes must all be excluded simply because there is no support to extend the synchronization of the decryption process to the case of data loss or random viewing of the media. Although an explicit sequence number alone does not provide any protection against complete loss of plaintext in the event of a bit error within the sequence number, it does help with error correction. It is used together with the resynchronization marker to limit the hazards caused by their own bit errors within the sequence number.

Content varies widely in complexity and value. This solution allows supporting encryption across the entire spectrum. This may require very efficient light algorithms that provide acceptable security. Additive stream ciphers are an ideal solution but require implicit or explicit order information, which is provided by this embodiment of the invention.

Thus, the key message is distributed from a separate server, so that the function of distributing encrypted content can be separated from the function of distributing a stream of key messages that decrypt the content. This also allows a separate entity to be responsible for charging and controlling the content decryption.

Such a system is essentially configured to implement the various embodiments of the method of the present invention described immediately above, providing corresponding advantages.

According to another aspect of the present invention there is provided a method of distributing digital data encoding content and configured into messages from a server to one or more clients over a network, each message being encoded so as to be decodable by a decoder application on a client terminal, the method comprising the steps of:

providing each message to a first service interface of a series of service interfaces installed on the server having at least one service interface between two layers within a protocol stack, each service interface being configured to add at least one packet header to packet encoding information enabling the client to process the remainder of the packet, the method further includes transmitting packets including at least one header that includes information enabling a service interface on the client to assemble each message derived by the decoder application from the payload of the packets, wherein the transmitted packet has a packet payload comprising a first segment and at least one further segment, each further segment comprising a resynchronization marker separating a message segment from an adjacent message segment comprising an explicit synchronization order, at least one of the message segments being encrypted in such a way that it decrypts each encrypted message segment independently of the other message segments.

Thus, a method of distributing content, such as may be produced by one embodiment of a method of producing cryptographically protected digital data encoding content in accordance with the invention, is provided. It is particularly useful for providing resiliency against network-induced errors and jitter.

According to another aspect of the present invention there is provided a server for distributing digital data encoding content and configured into messages from a server to one or more clients over a network, each message being encoded so as to be decodable by a decoder application on a client terminal, the server comprising:

a network interface for transmitting a plurality of data packets from a server over a network, each packet comprising at least a header and a payload, each payload comprising at least a part of a message, the server further comprising at least one service interface of a series of service interfaces, whereby each service interface is located between two layers of a protocol stack, each service interface being configured to add at least one packet header to packet coding information enabling a client to process the remainder of the packet, the server being configured to transmit packets comprising at least one header including information enabling a service interface on a client to assemble a decoder application for each message derived from the payload of the packets, wherein the server is configured to allocate packets having a payload comprising a first segment and at least one further segment, each further segment includes a resynchronization marker that separates a message segment from an adjacent message segment including an explicit synchronization order, wherein at least one message segment is encrypted in such a way that each encrypted message segment can be decrypted independently of the other message segments.

Such a server is useful for implementing a method of distributing content according to the present invention.

According to another aspect of the present invention there is provided a client terminal for receiving and processing digital data encoding content and arranged into messages, each message being decodable by a decoder application, the client terminal comprising:

an interface for receiving a plurality of data packets, each packet comprising at least a header and a payload, the terminal further comprising at least one service interface of a series of service interfaces, whereby each service interface is located between two layers in a protocol stack, each service interface being configured to remove at least a packet header from a packet and to process the remainder of the packet with information encoded in the removed packet header, the series of at least one service interface comprising a service interface configured to assemble a message derived from the payload of at least one packet by a decoder application using information included in at least one header of a packet, wherein the terminal is configured to receive packet payloads each comprising a first segment and at least one further segment, each further segment comprising a resynchronization marker comprising an explicit synchronization order separating a message segment from an adjacent message segment, to extract each segment by determining the location of the resynchronization marker, to decrypt each encrypted message segment independently of the other message segments, and to insert each decrypted message segment into the location from which it was extracted.

If some errors are introduced in the encrypted message during transmission, the client terminal can recover a large portion of the message. An error in one of the message segments does not affect the decryption of all other message segments into the original plaintext message segment because the client system can locate each individual message segment to decrypt it independently of the other message segments, i.e., without knowledge of the ciphertext or plaintext of the other message segments.

In a preferred embodiment, the terminal is configured to reassemble at least a portion of each received packet after decryption by adding at least one header to each packet for the payload having the inserted decrypted message segments before passing it to the service interface.

Thus, the presence of the resynchronization marker allows the payload of a packet to be decrypted before processing by the interface implementing the protocol stack (which may be, for example, a network protocol stack) on the client system. This provides for increased efficiency and allows for independence of the particular protocol stack used.

Preferably, the client terminal further comprises a network interface means for receiving data packets from a server over a network, wherein the added header comprises a header including a network address identifying the client terminal as the intended recipient of the packet.

In this variant, the decryption is performed completely "under the protocol stack". Thus providing a universally available conditional access system regardless of the specific type of terminal and network protocol.

According to another aspect of the present invention there is provided a method of receiving and processing content encoded and configured into messages in a client terminal, each message being decodable by a decoder application, said method comprising the steps of:

providing each packet to a first service interface of a series of service interfaces having at least one service interface between two layers in a protocol stack, each service interface being configured to remove at least one packet header from the packet and process the remainder of the packet with information encoded in the removed packet header, the series of at least one service interface including a service interface configured to assemble a decoder application with information included in the at least one header of the packet using messages derived from a payload of the at least one packet, wherein the received packet payload includes a first segment and at least one further segment, each further segment including a resynchronization marker separating a message segment from an adjacent message segment including an explicit synchronization order, wherein each segment is extracted by determining the position of the resynchronization marker, and wherein each encrypted message segment is decrypted independently of the other message segments, each decrypted message segment is inserted into the original extraction location of this segment.

This method, which is implemented by a client terminal according to the invention, has substantially the same advantages in terms of error recovery.

Brief description of the drawings

The invention will be described in more detail below with reference to the accompanying drawings, in which:

FIG. 1 is a schematic diagram of a data distribution system according to one embodiment of the present invention;

FIG. 2 is a schematic diagram of an encryption process according to one embodiment of the present invention;

FIG. 3 is a schematic diagram of a decryption process according to one embodiment of the invention;

FIG. 4 is a diagram illustrating the format of an MPEG-4 AU after encryption and the addition of an encapsulator and resynchronization marks in accordance with one embodiment of the present invention;

FIGS. 5A and 5B are diagrams illustrating a case of resynchronization with a resynchronization marker in the event of data loss according to one embodiment of the present invention;

FIG. 6 is a diagrammatic representation of a machine in the exemplary form of a computer system within which a set of instructions, for causing the machine to perform any one of the methodologies discussed herein, may be executed; and

fig. 7 is a schematic diagram of a data packet used to distribute part or all of a message through a network in the data distribution system of fig. 1.

Detailed Description

A method and system for a content level encryption protocol will now be described. In the following description, for purposes of explanation, numerous details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details.

In fig. 1, a content encryption system 1 is used to generate cryptographically protected data that encodes content. The data may be generated on the same system 1 or may be received from a separate source. In any case, the data is configured as a number of messages. Each message is decodable by a decoder application on one client system 2. By "message" is meant a data unit that the encoder application exchanges data with the decoder application. In one example employed throughout the description, each cryptographically secured message includes an encrypted MPEG-4 Access Unit (AU)3 (see fig. 4, 5A and 5B). An access unit is an individually accessible part of the data within an elementary stream. An elementary stream is a continuous stream of single media data from a single source entity to a single target entity at a compression layer (the layer comprising a decoder that converts between an encoded representation of the elementary stream and its decoded representation). It is to be noted, however, that the invention can also be used for other types of messages, such as MPEG-2 elementary stream packets.

In one embodiment, the encoded, encrypted message generated by the content encryption system 1 is transmitted to a first distribution server 4 (fig. 1) connected to the network 5 via a network interface, where it is stored. The client system 2 may access the encrypted content by downloading from the server 4. When the encrypted access units 3 are downloaded, they are encapsulated in synchronization layer packets (SL packets) each comprising a configurable header and a payload. The payload may comprise a complete access unit or a partial access unit. These SL packets are then mapped to another packet format used within the network 5, such as RTP, MPEG-2 transport stream packets, or UDP. It is of course also possible within the scope of the invention for the content encryption system 1 and the first distribution server 4 to be combined into a single server connected to the network 5.

In another embodiment, the encoded, encrypted message generated by the content encryption system 1 is stored on a content-bearing medium 6, such as a CD-ROM, DVD-ROM, or other suitable medium. The disc drive 7 is used to load the encoded, encrypted message from the content-bearing medium 6 into the client system 2. In this embodiment, the information is stored in files in access units in a format that allows an appropriate interface on client system 2 to retrieve and assemble the access units (e.g., into SL packets). This information also allows the client system 2 to transfer these access units after reading from the file to the appropriate decoder buffer and from there to the correct decoder application.

In both embodiments, the encrypted access units are stored in an MP4 file. MP4 files typically have a.mp 4 extension. The MP4 file format is designed to contain media information in an MPEG-4 representation in a flexible, extensible format that facilitates the exchange, management, editing, and presentation of media. Such a representation may be "local" to the system containing the representation, or may be over a network or other streaming mechanism. The file format is designed not to depend on any particular transfer protocol, but is typically able to support transfers efficiently. This design is based on the QuickTime format of Apple Computer, Inc.

Preferably, the content encryption system 1 encrypts the segments of the access units with at least one key (product or session key) having a round key value. The content may be encrypted with a single product key or a sequence of time-varying session keys, which are then encrypted with the product key. The same encryption scheme may be employed for video, audio and any associated data (content). That is, the present invention provides content level encryption of MPEG-4 media and data. Some examples of access unit encryption schemes are given below. In the preferred embodiment described herein, a symmetric algorithm is used, i.e. the decryption key is the same as the encryption key. This scheme satisfies the need for selective encryption at both intra and inter levels. (selective encryption may be desirable-an example may be less complex devices and less valuable content, encryption of I-frames may be warranted only, while other applications may require encryption of only texture or motion vector information.)

According to the invention, a unique sequence number is added to the message segment. The encryption used allows, for example, the client system 2 to decrypt each message segment independently of the other message segments, i.e., without knowledge of the data contained within the other message segments. The content encryption system 1 generates at least one key message, each key message carrying data linking at least one unique sequence number added to a message with a key value enabling at least some parts of the message to be decrypted.

These key messages preferably also form an MPEG-4 elementary stream, i.e. form access units, identified by an independent elementary stream identifier (ES _ ID). In the terminology of the MPEG-4 standard, these messages are referred to as IPMP (intellectual property management and protection) messages.

In one embodiment, IPMP messages flow from the first distribution server 4. In another embodiment, the IPMP message stream is downloaded by the client system 2 from the second distribution server 8. Alternatively, the IPMP message may be included in a separate file on a separately distributed key stream carrier 9, such as a CD-ROM, DVD-ROM, flash memory device, smart card, etc. carrier 9.

In one embodiment, the key values are provided separately. In this case, the key message contains a pointer linked to the sequence number so that the key can be retrieved by the client system 2. For example, the keys may be stored on a key stream carrier 9, while the IPMP message stream is provided by the second distribution server 8.

In another embodiment, the key message also contains a key value. Opaque data within the IPMP message stream may associate a key with the media in the following way:

<key：1 ES＝l seqNum.begin＝lseqNum.end＝54>

<key：2 ES＝l seqNum.begin＝54seqNum.end＝169>

<key：3ES＝1 seqNum.begin＝169seqNum.end＝289>

the DTS (transfer timestamp: indication of the nominal decoding time of the access unit) of the access unit carrying a round session key can be advanced so that it arrives before the corresponding encrypted media AU3 (which carries the data encoding the content). It is proposed that the DTS of the IPMP message flow be advanced by one key cycle period. This will have ample time to cope with network jitter and any pre-processing on the client system 2.

The information given above may then be used to associate the key data with any granularity of content access unit, regardless of the clock resolution of the receiving terminal.

As mentioned above, the presence of unique sequence information also allows the entire keystream to be transmitted before any media is transmitted. In this case the DTS of the medium access unit 3 is irrelevant and the synchronization is performed purely according to the value of the IPMP sequence number.

SUMMARY

The invention can be applied to all multimedia delivery systems where it is desirable to perform efficient content-level encryption of data (e.g., MPEG-4 data) with a round key. This includes various heterogeneous environments such as streaming over IP networks and the transport of MPEG-4 over MPEG-2 transport facilities or any other error-prone or error-free transport mechanism that can be used to transport MPEG-4 content.

As indicated above, one embodiment of the present invention is based on a framework for protecting MPEG-4 content that employs two different structures:

-a security wrapper for an MPEG-4 access unit; and

-encrypting the resynchronization mark.

These two structures will be discussed in detail below.

Detailed Description

Referring to fig. 4, the content encryption system 1 reads an original access unit 10 from a machine-readable medium. In this example the original access unit 10 is divided into three sections, independently encrypted, resulting in an encrypted access unit 3 comprising a first encrypted AU section 11, a second encrypted AU section 12 and a third encrypted AU section 13. The first resynchronization mark 14 is added to the second encrypted AU segment 12 separating it from the first encrypted AU segment 11. A second resynchronization mark 15 is added to the third encrypted AU segment 13 separating it from the second encrypted AU segment 12. The header 16 is prepended to the encrypted AU 3.

1. Security wrapper

In an exemplary embodiment of the invention, the security wrapper of the present invention may be viewed as a cryptographic envelope that provides security for any "wrapped" MPEG-4 access unit (video frame, audio sample, data unit). The issuer/server/holder protects the content by encapsulating each AU3 within these envelopes. The content can then only be opened by the end user with the appropriate key/rights. Various encapsulants are fairly common and occur in many cryptographic protocols. Thus, the present invention can work with a generic wrapper.

In one exemplary embodiment, the encapsulator can be specified specifically for use in an MPEG-4 environment. In addition, the present invention can utilize the characteristics (sequence number, etc.) of the wrapper to perform "double-tasking" and perform random access by also providing the ability for the round key. Thus, the present invention can operate by taking many widely used protocols and adding some specialized structures (such as resynchronization markers 14, 15) to create a solution by putting these specialized structures together within a framework and using them in some way.

The header 16 shown below (and shown schematically in figure 4) is intentionally added beforehand to each encrypted AU 3:

the header includes the following fields:

version-2 bits version field 17. Set to zero for the first revision.

An E-bit flag 18 indicating whether the payload is encrypted (1) or unencrypted (0). Note that only the payload portion is encrypted.

An A-bit flag 19 indicating the presence of a (1) or absence of a (0) captcha field. The authentication code, if present, relates to the entire structure-the encapsulator 16 and AU 3.

CRM-bit flag 20, indicating the presence (1) or absence (0) of a cryptographic resynchronization mark 14, 15 within AU 3.

Reserved-field 21 of three reserved bits set to zero.

Sequence number-a unique sequence number, carried in the sequence number field 22. Methods of generating serial numbers are considered to be outside the scope of this document. The value may be monotonically increasing because Hamming distance corruption in count mode does not pose a significant threat to AES. The length of this field 22 is not preset because it is in a self-describing format. The lower seven bits of each byte are used to carry the sequence number. The high order bit of each byte, if set, indicates that there is another byte present, and the Most Significant Bit (MSB) of the last byte is set to zero. As an example, the value 350 would be expressed as:

11010111 00000010

captcha-an optional field (not shown in fig. 4), carries a self-describing captcha. The framework is agnostic to the authentication encoding scheme to be used, but it is assumed that keyed Hash (HMAC) would be the most appropriate. Digital signatures meet the requirements, but it can be considered that these current schemes are too uneconomical to perform at AU level. Note that the entire structure-header 16+ AU 3-is verified.

Payload-original AU 10 or encrypted AU 3. If the crypto-resynchronization marks 14 and 15 are used, the encrypted AU3 is larger than the original AU 10.

2. Cryptographic resynchronization marker

To achieve cryptosync, the tags 14, 15 carry some unique and explicit synchronization information 23, 24, respectively, so that the cryptogram can be "reset" in case of data loss.

The following is a cryptographic resynchronization mark that performs well in the encrypted domain. This flag is byte aligned and includes 16 zeros followed by a variable length self-describing sequence count:

0000 0000 0000 0000 XXXX XXXX

in application, multiple cryptographic resynchronization marks 14, 15 may be inserted within an AU 3. The position of the markers 14, 15 within the AU3 is easily locatable and therefore guaranteed to be unique. There will still be a small statistical probability of causing a collision because a given plaintext/key combination can produce ciphertext having the form 000000000000. Although this is a very small probability of occurring, the possibility of such tag contention can be completely eliminated by using an escape code. In such an embodiment, the existence of a contended resynchronization marker is indicated by "escaping" the contended resynchronization marker in a manner similar to a C language escape code.

For typical applications in an error prone environment, several resynchronization marks 14, 15 may be inserted within a given AU 3. Each body of the resynchronization marker 14, 15 contains a unique count 25, 26, having the same format and purpose as the serial number in the security seal. The proposal counts 25, 26 are monotonically incremented from the initial sequence number carried within the header 16.

Damaging or losing the sequence numbers contained in the header 16 does not result in the loss of the entire encrypted AU 3. The sequence number within the resynchronization mark is preferably absolute, rather than specified as an offset from the sequence count specified in header 16. It is also important to ensure that the value of the sequence number in the header of the next AU is greater than the last sequence number used in the current AU3 to avoid deep use of the cipher.

The following is an example of a resynchronization mark with a value of 351:

0000 0000 0000 0000 1000 0010 0101 1111

if data is lost, synchronization is achieved by locating the next resynchronization marker and restarting the password with the sequence value in the marker body as an input to the IV.

Implementation of

1. Encryption

Fig. 2 is a schematic diagram of an encryption process according to a preferred embodiment of the present invention. The count 27 is formed by a adulteration (selling) key 28, a sequence number 29 and a chunk marker 30. An encrypted count 31 is generated with a key 32 having a round value. The encrypted count is exclusive-or (XOR) with an unencrypted AU block of data 33 to produce an encrypted AU block of data 34.

The AES/Rijndael algorithm has been chosen for media encryption. The cryptogram operates in a counting mode, taking advantage of the explicit count (sequence number and cryptogram resynchronization marker) carried within the media.

The Rijndael algorithm was chosen as a new Federal Information Processing Standard (FIPS) for data encryption, ready to replace the old DES and Triple DES standards.

The AES algorithm has undergone a significant amount of cryptanalysis during the selection process. The analysis effort towards AES is comparable to DES. It is generally accepted that the well-known deciphering method is an exhaustive search of the key space.

Some highlights of AES are:

exempt from royalties and not categorised

Available for international outlets

Allowing variable 128, 192 and 256 key and block lengths. All nine combinations of key/block lengths are possible.

Hardware and software implementations improve significantly over DES in speed:

8.416kB/s at 8051 at 20MHz

8.8MB/s on 200MHZ Pentium

These numbers are for ECB mode. The counting mode requires only one additional XOR operation and thus the added overhead is negligible.

The counting mode comes from the requirement of high-speed encryption of the ATM network, and requires the parallelization of the encryption algorithm.

Count mode encryption operates by applying an encryption function to a monotonically increasing count 27, resulting in a one-time pad. This pad is then xored with the plaintext. The decryption operation is the same.

The counting mode requires that the sender and receiver share a count in addition to the usual key 32. Note that the count 27 need not be kept secret.

For encryption:

ci ═ Pi XOR E (count)

For decryption:

pi is Ci XOR E (count)

Wherein:

e () is an encryption function of the block cipher.

Ci is the ith block of the ciphertext.

Pi is the ith block of plaintext.

It is of utmost importance that the same count value is not used for the same key, since the interpreter can thus xor two cipher blocks to obtain the xor of two corresponding plaintext blocks.

The advantages of the counting mode are:

1. software efficiency preprocessing may be used in some circumstances because the generation of the keystream is not message dependent. Padding may be calculated during some spare periods, even before the media is available. When the media is available, it is simply xored with the padding. This can result in tens of Gb/s throughput on a modern processor.

2. The hardware efficiency count mode is fully parallelizable. Blocks C1, C2... Cn may both be decrypted at the same time.

3. Random access is not linked and therefore decryption of block Ci is not dependent on block Ci-l.

The 4.1 bit error of the error extended ciphertext is limited to the corresponding bit in the plaintext. This is a highly desirable property for streaming video applications in lossy environments.

5. Both the low complexity encryption and decryption processes depend on the encryption function E (). This is an important criterion when the reverse direction of the password D () -1 differs greatly from the "positive" direction. This is the case for Rijndael and many other block ciphers. This facilitates a solution that is very hardware and software inefficient.

6. The security is as secure as the basic block cipher.

7. The ciphertext does not grow, except for the explicit resynchronization marker.

Such passwords are commonly used because they are known to be robust against a set of comparable deciphering methods and are subject to extensive analysis by the world cryptology community. This password itself is almost universal and accepted by NIST (national institute of standards and technology). Such ciphers support a key length of at least 128 bits. Scalability is important because ideally the same cipher should be able to parametrize to protect content that may vary greatly in value, from 3 minute video clips to the amazing production of hollywood. A key length in excess of 128 bits may be excessive for some applications; supporting longer keys may be considered an advantage. The use of a single parametrization algorithm also predicts economies of scale, and is beneficial to silicon wafer suppliers. The present invention does not employ implicit ciphers or well-known ciphers in implicit mode. Such cryptographic systems are self-synchronizing, provide random access or search capabilities, and can recover from data loss situations. Although these are different cases, in practice they depend on the same criteria: the shortage of all or part of the previous data blocks does not affect the ability to decrypt the current data block. It can thus be assumed that reliable (explicit or implicit) continuation information is available for the data to be decrypted. Such a cryptographic system provides good error propagation characteristics. Single bit error expansion (one bit error in ciphertext causes only a corresponding bit-specific error in plaintext) is very important. No scheme is applied that has the error spreading characteristics of the same block, multiple blocks, or infinite blocks. Such passwords provide good performance in the hardware and software of many computing environments. Key establishment time, key agility, and parallelism are all important. The choice of algorithm reflects a "safe at every point" strategy, where some acceptable security compromise is made for efficiency and complexity reduction. Such cryptographic systems provide a small data expansion. The resulting ciphertext has a length that is the same as or close to the length of the plaintext, and the length of any additional "security headers" is kept to a minimum. More than one message may be encrypted with the same product or session key without sacrificing security in any way.

2. Decryption

Fig. 3 is a schematic diagram of a decryption process (without symmetry of the encryption/decryption process) according to an embodiment of the present invention.

In an exemplary embodiment of the invention, decryption proceeds as follows:

the decryption engine checks the encryption flag 18 within the encapsulator of AU 3. If the flag 18 is not set and no verification is used, the encapsulator can simply be deleted and the original AU3 passed to the decoder.

If AU3 is encrypted, the sequence number within the wrapper is extracted to produce the count 27.

The count block length is the same as the selected AES block length. This requirement is due to the count 27 being input to the block cipher. This approach is scalable in that it is comparatively easy to fill the count 27 to a larger length in the case where a larger AES block length is specified.

For purposes of this document, it will be assumed that the AES block length is 128 bits:

031	3295	96127
031	3295	96127	adulteration key (optional)	Serial number	Block label

The spoofing key 28 is optional, but it should be noted that the absence of the spoofing key 28 may result in a complete breakdown of security in the case of multiple bit streams encrypted with the same key 32. (e.g., if audio and video are encrypted with the same product and session key, one or more spoofing keys 28 are used to prevent deep use of the cipher.) the value of the spoofing key 28 need not be secret.

The 32-bit block index 30 is the block count within a single AU 3. The first 128-bit block of an AU has a block index of 0; the next 128-bit block has a block index of 1, and so on. The block markers are reset to zero after each resynchronization mark 14, 15. Note that the value of the chunk marker 30 is not sent, but is calculated by the encryption and decryption process.

The block mark 30 must never loop during processing of one AU 3. Assuming the worst case is that the AES block length is 128 and the video AU3 length is maximum, a block length of 32 bits provides sufficient headroom.

The count block 27 is then used as an input for the AES block cipher during the padding calculation. The processing for the ith block of an AU is:

Ci-Pi XOR E (count) for encryption process

Pi-Trunc (n, Ci XOR E (count)) for the decryption process

Wherein:

e () is the encryption function of the AES cipher.

Ci is the i-th block of the encrypted MPEG-4 AU.

Pi is the first n bytes of the ith block of the original AU data, and the value of n is between 1 and the block length.

It is assumed that the length of each AU3 is provided to the decryption tool together with the AU data.

The Trunc (x, y) function intercepts the first x bytes of the y value.

In the case of the use of cryptographic resynchronization marks 14, 15, the following actions must be taken:

CRM tags 20 are verified. If CRM is present within AU3, decryption continues as above until a CRM is encountered.

The bit stream is checked to ensure that the CRM is not a contended CRM that has been escaped. If this is not a contended token, the token should be "non-escape" and decryption should proceed as normal.

If the tag 14, 15 is valid, a new count 27 should be generated with the body of the tag:

031	3295	96127
031	3295	96127	adulteration key (optional)	Cryptographic resynchronization marker	Block label

The block marker 30 is reset to zero and decryption is performed using this new count value as input to the password.

3. Cryptographic system configuration

In an exemplary embodiment of the invention, some parameters may need to be set in order to make efficient use of the cryptographic system.

These parameters may include, for example:

authentication scheme to be employed (if any)

The adulteration key 28, which need not be secret, may be carried with configuration information

Decryption cipher and mode if not specified, AES assumed to be count mode

Description of exactly what data is encrypted, if intra-frame selective encryption is employed.

This information is carried within the IOD (initial object descriptor). The exact format of the data structure to be used is beyond the scope of this document.

Fig. 6 shows a diagrammatic representation of machine in the example form of a computer system 35 within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed. In other embodiments, the machine may comprise a set-top box (STB), a network router, a network switch, a network bridge, Personal Digital Assistant (PDA), a cellular telephone, a web appliance or any machine capable of executing a set of instructions that specify operations to be performed by that machine.

The computer system 35 includes a processor 36, a main memory 37 and a static memory 38 that communicate with each other via a bus 39. The computer system 35 may also include a video display unit 40 (e.g., a Liquid Crystal Display (LCD) or a Cathode Ray Tube (CRT)). The computer system 35 also includes an alphanumeric input device 41 (e.g., a keyboard), a cursor control device 42 (e.g., a mouse), a disk drive unit 43, a signal generation device 44 (e.g., a speaker), and a network interface device 45.

The disk drive unit 43 includes a machine-readable medium 46 having stored thereon a set of instructions (i.e., software) 47 embodying any one, or all, of the methodologies or functions described herein. The software 47 is also shown to reside, completely or at least partially, within the main memory 37 and/or within the processor 36. The software 47 may also be transmitted or received via the network interface device 45. For the purposes of this specification, a "machine-readable medium" shall be taken to include any medium that is capable of storing, encoding or carrying a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methodologies of the present invention. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.

Fig. 5A and 5B together form a schematic diagram of resynchronization in the event of data loss with cryptographic resynchronization marks 14, 15 according to an embodiment of the present invention. Fig. 5A shows the prior art, without the resynchronization mark present. The encrypted AU3 has only a header 16 pre-assigned to it. Assume that client system 2 receives an encrypted access unit 3 with a block of data 49 missing. With a block cipher in count mode, only the sequence number of the header 16 is available as an initialization vector, and the client system 2 can correctly decrypt the encrypted access unit 3 to the lost data 49. After that it will continue to decrypt the encrypted access unit 3 but with the wrong count value to fit the wrong block of data, thus producing a scrambled plaintext. In practice the decryption process will produce one block 50 of data recovered and one (larger) block 51 of lost AU data.

By contrast, with the cryptographic resynchronization mark 14, 15, as shown in fig. 5B and 4, this means that the decryption process will produce a first recovered AU data portion 52, a (much smaller) block 53 of missing AU data, and a second recovered AU data portion 54. This is because the client system 2 is able to identify the explicit synchronization information 23 and 24 within the resynchronization marks 14 and 15, respectively. The first, second and third AU segments 11-13 are extracted and independently decrypted.

Referring now to fig. 7, there is shown a schematic diagram of an IP packet 55 used to distribute encrypted AU3 to client system 2 via network 5. The IP packet 55 includes an IP header 56 that includes a network address that allows the client system 2 to know whether it is the intended recipient of the IP packet 55. The IP address may be a unique address, a multicast address, or a broadcast address, as is known in the art.

In this exemplary embodiment, UDP is used as the transport protocol. The IP packet 55 therefore comprises a UDP header 57. Furthermore, the encrypted access unit 3 has been encapsulated by an application implementing the synchronization layer specified in the MPEG-4 standard on the first distribution server 4. Thus, the IP packet includes a SL header 58. After the SL header 58 is a header 59 that forms a security seal. Which is identical to the header 16 described above but also includes an explicit synchronization sequence 60 identical to the explicit synchronization information of the cryptographic resynchronization marks 14, 15. Header 59 also includes bit flag 18 indicating encryption of access unit 3, bit flag 19 indicating authentication, CRM flag 20, reserved field 21, and sequence number field 22. The header 59 is followed by the first encrypted AU segment 11. The second encrypted AU segment 12 is separated from the first encrypted AU segment 11 by a first cryptographic resynchronization mark 14 comprising synchronization information 23 and a count 25. The third encrypted AU segment 13 is separated from the second encrypted AU segment 12 by a second cryptographic resynchronization mark 15 comprising synchronization information 24 and a count 26.

The present invention advantageously uses the synchronization information 23, 24, 60 to effect a type of decryption referred to as under-stack decryption. Such decryption is more fully described in co-pending international patent application PCT/US01/41361 by the applicant of the present application.

The client system 2 includes an interface that implements the IP protocol. That is, the interface processes the IP packet 55 with information in the IP header 56 that determines what needs to be done with the rest of the IP packet 55. Typically, however, this remainder is passed to an interface implementing a higher layer protocol (in this case the UDP protocol) and from there onwards to another interface, in this example an interface implementing an MPEG-4 synchronisation layer, in this embodiment of the invention the IP packet 55 being decrypted first.

In this embodiment, the client system 2 receives as input the entire IP packet 55 from the interface implementing the IP protocol on the client system 2. The rest of the relevant IP packet 55 is agnostic, but it searches for data within the payload of the IP packet 55 for explicit synchronization information 23, 24, 60. It then extracts the encrypted message segments from the IP packet 55 and decrypts them in the manner described above. The IP packet 55 is then reassembled and passed back to the interface implementing the IP protocol on the client system 2 for processing by the respective interface implementing the other protocol (i.e., UDP, SL).

Thus, a method and system for a content level encryption protocol is described above. While the present invention has been described in connection with specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method of generating cryptographically protected digital data encoding content and configured into messages, each message being encoded so as to be decodable by a decoder application on a client terminal having a service interface for assembly with each message for the decoder application, the method comprising the steps of:

retrieving a message from a machine-readable medium;

encrypting at least a portion of the message; and

providing as output the encrypted message in a format enabling a server service interface to configure the message into at least one packet comprising at least one header and a payload, each payload comprising at least a portion of the message, the at least one header comprising information enabling the service interface at the client to assemble each message for the decoder application from the payload of the packets,

wherein the method comprises dividing each message into a first message segment and at least one further message segment, wherein at least one message segment is encrypted in such a way that it decrypts each encrypted message segment independently of the other message segments, and wherein the encrypted message is assembled by adding to at least the further message segment a resynchronization marker comprising explicit synchronization information separating one encrypted message segment from a neighbouring message segment.

2. The method of claim 1, wherein the message segment is encrypted with at least one key having a round-robin value.

3. The method of claim 1, wherein each resynchronization mark further comprises a unique sequence number.

4. The method of claim 1, further comprising adding an encapsulator encapsulating each encrypted message and including a unique sequence number.

5. A method according to claim 3 or 4, wherein each unique serial number is given in a self-describing format.

6. A method according to claim 3 or 4, wherein message segments are encrypted using at least one key having a round-robin value, the method further comprising generating at least one key message, each key message carrying data linking at least one unique sequence number added to a message with a key value enabling decryption of at least parts of the message.

7. The method of claim 3 or 4, further comprising encrypting the message segments with a cipher in cipher mode using feedback, wherein the cipher is reinitialized at the beginning of each message segment.

8. The method of claim 7, wherein a unique sequence number within a resynchronization mark separating a further message segment from another message segment is used as an initialization vector for encrypting the further message segment.

9. The method of claim 1, wherein a block cipher is used to encrypt a message segment, the encryption using a cipher having a block length equal to a divisor of the length of the message segment.

10. The method of claim 1, further comprising employing a cipher in a count mode, wherein the count is reset prior to encryption of a message segment.

11. The method of claim 10, wherein each resynchronization mark further comprises a unique sequence number, and wherein a unique sequence number within a resynchronization mark separating a further message segment from another message segment is used to form a count of the encryption of said further message segments.

12. A method as claimed in claim 10 or 11, wherein messages belonging to separate elementary streams are encrypted, each stream being intended for a decoder application on the client, the method comprising providing as output the encrypted messages in a format which enables a service interface on the client to assemble the messages into the separate elementary streams, wherein the count is formed by a bogus key, a different bogus key being used for the messages of each elementary stream.

13. A method of distributing digital data encoding content and configured into messages from a server to one or more client terminals over a network, each message being encoded so as to be decodable by a decoder application on a client terminal, the method comprising:

transmitting a plurality of data packets from the server through the network interface of the server and a network, each packet comprising at least a header and a payload, each payload comprising at least a portion of a message;

providing each message to a first service interface in a series of at least one service interface installed on the server between two layers in a protocol stack, each service interface being configured to add at least one packet header to packet encoding information enabling the client to process the remainder of the packet, the method further comprises transmitting packets comprising at least one header, said header comprising information enabling a service interface on the client to assemble each message for the decoder application from the payload of the packets, wherein the transmitted packets each have a packet payload comprising a first segment and at least one further segment, each further segment comprising a resynchronization marker separating a message segment from an adjacent message segment and comprising an explicit synchronization order, wherein at least one of the message segments is encrypted in a manner that decrypts each encrypted message segment independently of the other message segments.

14. The method of claim 13, wherein the message segments are encrypted to be decryptable with at least one key having a round key value.

15. The method of claim 13, including transmitting packets wherein each resynchronization mark comprises a unique sequence number.

16. A method according to claim 13, the method comprising transmitting packets in which each message is encapsulated by an encapsulator comprising a unique sequence number.

17. A method according to claim 15 or 16, wherein each unique serial number is given in a self-describing format.

18. A method according to claim 15 or 16, wherein message segments are encrypted in such a way that they are decrypted using at least one key having a round-robin key value, and the method further comprises transmitting at least one key message, each key message carrying data linking at least one unique sequence number included in one message with a key value enabling decryption of at least parts of this message.

19. A server for distributing digital data encoding content and configured into messages to one or more client terminals over a network, each message being encoded so as to be decodable by a decoder application on a client terminal, the server comprising:

a network interface for transmitting a plurality of data packets from said server over a network, each packet comprising at least a header and a payload, each payload comprising at least a part of a message, said server further comprising at least one service interface of a series of service interfaces, whereby each service interface is located between two layers within a protocol stack, each service interface being configured to add at least one packet header to packet coding information enabling the client to process the remainder of the packet, said server being configured to transmit packets each comprising at least one header, said headers comprising information enabling a service interface on the client to assemble each message for a decoder application from the payloads of the packets, wherein said server is configured to allocate packets having a packet payload comprising a first segment and at least one further segment, each further segment includes a resynchronization marker that separates a message segment from an adjacent message segment and includes an explicit synchronization order, wherein at least one message segment is encrypted in a manner that decrypts each encrypted message segment independently of the other message segments.

20. The server of claim 19, wherein the message segments are encrypted in a manner that decrypts them with at least one key having a round key value.

21. A server according to claim 19, said server being configured to transmit packets wherein each resynchronization mark comprises a unique sequence number.

22. A server according to claim 19, said server being configured to transmit packets wherein each message is encapsulated by an encapsulator comprising a unique sequence number.

23. A server according to claim 21 or 22, configured to give each unique serial number in a self-describing format.

24. A server according to claim 21 or 22, wherein message segments are encrypted in such a way that they are encrypted using at least one key having a round-robin key value, and said server is further configured to send at least one key message, each key message carrying data linking at least one unique sequence number included in one message with a key value enabling decryption of at least parts of this message.

25. A client terminal for receiving and processing digital data encoding content and configured into messages, each message being decodable by a decoder application, the client terminal comprising:

an interface for receiving a plurality of data packets, each packet comprising at least a header and a payload, said terminal further comprising at least one service interface of a series of service interfaces, whereby each service interface is located between two layers in a protocol stack, each service interface being configured to remove at least one packet header from a packet and to process the remainder of the packet with information encoded in the removed packet header, said series of at least one service interface comprising a service interface configured to assemble messages for decoder applications from the payload of at least one packet with information included in the at least one header of the packet, wherein said terminal is configured to receive packet payloads each comprising a first segment and at least one further segment, each further segment comprising a resynchronization marker separating a message segment from an adjacent message segment and comprising an explicit synchronization order, to extract each segment by determining the location of the resynchronization marker, to decrypt each encrypted message segment independently of the other message segments, and to insert each decrypted message segment into the location from which it was extracted.

26. The client terminal of claim 25, wherein said terminal is configured to decrypt message segments with at least one key having a round key value.

27. A client terminal according to claim 25, said terminal being configured to retrieve a unique sequence number from each resynchronization mark.

28. A client terminal according to claim 25, wherein each encrypted message is encapsulated by an encapsulator, the client terminal being configured to retrieve a unique sequence number from each encapsulator.

29. A client terminal according to claim 27 or 28, wherein said client terminal is configured to derive the length of a field containing a unique sequence number by analysing a unique sequence number in a self-describing format.

30. A client terminal according to claim 27 or 28, wherein said terminal is configured to decrypt message segments using at least one key having a round-robin key value, and said client terminal is further configured to receive at least one key message, each message carrying data linking at least one unique sequence number added to a message with a key value enabling decryption of at least some part of this message, and to select the key value using the data.

31. A client terminal according to claim 27 or 28, said client terminal being further configured to decrypt message segments with a cipher in cipher mode using feedback, and to reinitialize the cipher at the start of each message segment.

32. A client terminal according to claim 31, said client terminal being configured to use a unique sequence number within a resynchronisation marker separating a further message segment from another as an initialisation vector for decrypting the further message segment.

33. The client terminal of claim 25, said client terminal further configured to decrypt a message segment with a block cipher and, for said block cipher, to use a cipher text block length equal to a divisor of the message segment length.

34. The client terminal of claim 25, the client terminal further configured to use a password in a count mode and reset the count before decrypting a message segment.

35. A client terminal according to claim 34, configured to retrieve a unique sequence number from each resync marker, said client terminal further configured to use a unique sequence number within a resync marker separating a further message segment from another as a count for decrypting the further message segment.

36. A client terminal according to claim 34 or 35, said client terminal being further configured to receive and process messages belonging to separate elementary streams, each elementary stream to be used by a decoder application installed on the client terminal, wherein the service interface on the client terminal is configured to assemble the messages into the separate elementary streams, wherein said client terminal is further configured to form a count from the spoofing key, using a different spoofing key for each elementary stream's messages.

37. A client terminal according to claim 25, wherein said client terminal is configured to reassemble at least a portion of each received packet after decryption before transmission to the service interface by adding at least one header of each packet to the payload with the decrypted message segment inserted.

38. The client terminal according to claim 37, said client terminal further comprising a network interface means for receiving data packets from a server over a network, wherein the added header comprises a header including a network address identifying the client terminal as the intended recipient of the packet.

39. A method of receiving and processing digital data encoding content and configured into messages in a client terminal, each message being decodable by a decoder application, the method comprising:

providing each packet to a first service interface in a series of at least one service interface between two layers in a protocol stack, each service interface being configured to remove at least one packet header from the packet and to process the remainder of the packet with information encoded in the removed packet header, the series of at least one service interface comprising a service interface configured to assemble a message for decoder application from the payload of at least one packet with information included in the at least one header of the packet, wherein the received packet payload comprises a first segment and at least one further segment, each further segment comprising a resynchronization mark separating one message segment from an adjacent message segment and comprising an explicit synchronization order, wherein each segment is extracted by determining the position of the resynchronization mark, and wherein each encrypted message segment is decrypted independently of the other message segments, each decrypted message segment is inserted into the original extraction location of this segment.

40. The method of claim 39, wherein the message segments are decrypted using at least one key having a round key value.

41. The method of claim 39, comprising retrieving a unique sequence number from each resynchronization mark.

42. The method of claim 39, wherein each encrypted message is encapsulated by an encapsulator, the method comprising retrieving a unique sequence number from each encapsulator.

43. A method according to claim 41 or 42, the method comprising deriving the length of a field containing a unique sequence number by analysing a unique sequence number in a self-describing format.

44. A method according to claim 41 or 42, wherein message segments are decrypted using at least one key having a round-robin key value, and the method further comprises receiving at least one key message, each message carrying data linking at least one unique sequence number added to a message with a key value enabling decryption of at least some part of the message, and using the data to select the key value.

45. A method according to claim 41 or 42, further comprising decrypting the message segments with a cipher in cipher mode using feedback, and re-initialising the cipher at the start of each message segment.

46. The method of claim 45, including using a unique sequence number within a resynchronization mark separating a further message segment from another message segment as an initialization vector for decrypting the further message segment.

47. The method of claim 39, further comprising decrypting a message segment with a block cipher and employing, for the block cipher, a cipher text block length equal to a divisor of the message segment length.

48. The method of claim 39, further comprising employing a cipher in a count mode and resetting the count before decrypting a message segment.

49. The method of claim 48, including retrieving a unique sequence number from each resynchronization mark, and further including using a unique sequence number within a resynchronization mark separating a further message segment from another message segment as a count for decrypting the further message segment.

50. A method as claimed in claim 48 or 49, the method further comprising receiving and processing messages belonging to separate elementary streams, each elementary stream to be used by a decoder application installed on the client terminal, wherein the service interface on the client terminal is arranged to assemble the messages into the separate elementary streams, wherein the method further comprises forming the count from a bogus key, using a different bogus key for the messages of each elementary stream.

51. A method according to claim 39, the method comprising reassembling at least a portion of each received packet after decryption by adding at least one header of each packet to the payload with the inserted decrypted message segment, for transmission to the service interface.

52. A method according to claim 51, wherein the data packet is received by a network interface device of the client terminal, the method comprising adding a header including an address identifying the client terminal as the intended recipient of the packet.