GB2387518A - Encryption and decryption of MPEG data streams - Google Patents

Abstract

Encrypting and decrypting a digital object comprising data representative of video, audio and private material. The digital object is in an MPEG data format and the method comprises splitting 14 the digital object into respective streams of multiple packets of particular data types, encrypting at least some data of the payloads of the packets in blocks of a pre-determined size in accordance with the Advanced Encryption Standard (AES). For sub-packets of video material, data is only encrypted at the slice level and below. In one embodiment the method comprises a plurality of encryptors, each being configured to encrypt a particular data type. In a further embodiment the digital object comprises an encryption tag indicative of a location of the encrypted data within the respective data stream. The decryption process is essentially the reverse of the described encryption process and similarly comprises splitting the encrypted digital object into respective streams of multiple packets of particular data types.

Description

METHODS AND APPARATUS FOR

ENCRYPTION AND DECRYPTION

The present invention relates to methods and apparatus for encryption and decryption of data, and in particular, but not exclusively, to methods 5 and apparatus for encryption and decryption of video and audio material in MPEG format.

Digital video, music and sound encryption/decryption software process that will be used by companies wishing to protect their digital media assets and also those wishing to gain revenue from providing restricted 10 access to these digital media.

The advent of digitally produced media [video, music and sound] has resulted in substantial security problems for many organizations, due to the ease of reproduction, distribution, and lack of degradation when copied of digitally produced media.

15 The need to protect media files (whether for Digital Rights Management, revenue management or content tracking and usage management) is a significant issue for corporations and public sectors. PC/Broadcast convergence will offer new markets for this application, enhancing or replacing Set-Top Boxes with software solutions.

20 Currently, one known way to protect digital video content is to use some form of elementary encryption (usually at the "Header" level) and/or inserting some form of watermarking as a tracing element to prove authenticity.

The problems associated with these processes are: À Encrypting at the "Header" level changes the encoding of the video and renders it unplayable in the vast majority of hardware systems (such as CD-ROM/DVD players). This means that its use is 5 restricted to niche markets, receiver - not a mainstream receiver.

À Watermarking entails a further activity in the editing process and is only really of value in identifying whether a digital video files is genuine or not. A bit like "shutting the gate after the horse has bolted". 10 MPEG audio-visual content is the widest used standard for digital media compression world-wide. Everything from games consoles through DVD- Video to digital terrestrial, cable and satellite broadcasts use MPEG standards for compression of their audio-visual data. A number of international standards comprise the MPEG family, including 15 À ISO/IEC 11172 (MPEG-1)

À ISO/IEC 13818 (MPEG-2)

À ISO/IEC 14496 (MPEG-4)

In highly preferred embodiments of the invention the present invention seeks to provide an improved method of encrypting data in MPEG 20 format.

According to a first aspect of the invention there is provided a method of encrypting a digital object, the digital object comprising a plurality of packets of data, the method comprising separating the digital object into respective streams of multiple packets of particular data types, encrypting

at least some data of at least one data type in blocks of a predetermined size and then combining the streams of data types into an encrypted digital object.

The digital object to be encrypted may be in the form of static data, such S as a stored file or may be in the form of material which is streamed from a remote location.

Preferably the data types comprise at least one of data representative of visual material, audio material and private material. The data representative of visual material is most preferably representative of 10 video material.

The method preferably comprises combining the streams of data types into an encrypted data stream.

Desirably the method comprises selectively encrypting at least one particular data type. The method may comprise selectively encrypting at 15 least some data of at least some of the packets of at least one particular data type.

The method preferably comprises retrieving the digital object from a memory buffer.

Preferably the method comprises encrypting a digital object which is an 20 MPEG format.

Advantageously data in an MPEG standard may be encrypted regardless of whether the data is stored on CD-ROM. DVD, over the Internet or from a hard drive or any portable storage device.

Preferably data is encrypted in accordance with the AES (Advanced Encryption Standard). Most preferably the Rijudael implementation of the AES. AES (Rijndael) is an iterated block cipher with a variable block length and a variable key length. The block length and key length 5 may be specified to 128, 192 or 256 bits.

Preferably the method comprises arranging that subsequent to encryption the digital object comprises a plurality of least partially encrypted packets of variable length.

Preferably the digital object comprises multiple packets of variable 10 length, each packet comprising a packet and a payload and the payload of each packet comprises a plurality of sub-packets, each sub-packet comprising a header and a payload, only some of the sub-packets are encrypted. Preferably where the sub-packets represent hierarchical layers of video 15 material in an MPEG standard, the method comprises encrypting data at the Slice Level and below. Most preferably data at a layer higher than the slice layer is not encrypted.

Preferably where the size of the data to be encrypted is not an integer multiple of the predetermined block size, additional data from another 20 packet, or data from another sub-packet of the packet is added to the data to be encrypted to form a combined data block, the combined data block then being encrypted. Preferably the encrypted additional data is then returned to its originating packet or sub-packet.

Alternatively, where the sine of the data to be encrypted is not an integer 25 multiple of the predetermined block size the data is encrypted with

stuffing data, the stuffing data being appended to a payload of a packet or a respective sub-packet.

Where the size of the data to be encrypted is not an integer multiple of the predetermined block size, data which is in excess of an integer 5 multiple of the predetermined block size is left unencrypted.

Preferably the digital object is in a format which is suitable for use in relatively error free environments. In a preferred embodiment the digital object comprises a plurality of Packetised Elementary Stream Packets.

Preferably the digital object is representative of at least one of visual 10 material, audio material and private data.

Preferably where the digital object comprises multiple data types, the method comprises inserting synchronization markers into each data type at respective corresponding locations such that decryption of the encrypted digital object can begin from a chosen point in the encrypted 15 digital object.

Locations prior to the synchronization markers may be provided with padding data such that encryption of data subsequent to the synchronization markers starts on an integer multiple of the predetermined block size.

20 Alternatively, the method may comprise leaving some of the data prior to the synchronization markers unencrypted. The actual number of bytes that would be left unencrypted is the remainder of the number of bytes suitable for encryption divided by the encryption block size.

Thus, for example, if 3190 bytes of encryptable data have been received at the point at which a new synchronization marker is encountered, we have encrypted 99 packets of 32 bytes each, and have 22 bytes left unencrypted. 5 The method desirably comprises incorporating a tag into the digital object, the tag being indicative of whether a portion of the digital object is encrypted. The tag is preferably indicative of which data types of the portion are encrypted.

Where the digital object is in MPEG format the tag is preferably 10 provided as Private Data.

According to a second aspect of the invention there is provided apparatus for encrypting a digital object, the apparatus comprising a data type separator, a plurality of encryptors each being configured to encrypt a particular data type, and a multiplexer, the arrangement of the apparatus 15 being such that, in use, a digital object comprising multiple data types is input into the data type separator, the data type separator being configured to separate out the data types into respective data streams and input each data stream into a respective encryptor, the encryptors being operative to encrypt at least some data of at least one data type in blocks 20 of a predetermined size, and the multiplexer being operative to combine the data streams which issue from the encryptors into an encrypted digital object. The effect of using a multiplexer is to drastically reduce the time-scales required for encrypting the data (because virtually no time is spent 25 making deterministic decisions about what data to encrypt) and so be able to provide real-time encryption.

Another major advantage of utilising a multiplexer is that support for the range of MPEG data formats can be enabled with only minimal changes to the implementation. This will result in a significant cost saving and allow future technologies to be delivered in shorter time-scales.

5 Preferably the encryptors are configured to encrypt blocks of data of a predetermined size.

Preferably the data type separator comprises a stream splitter which is operative to retrieve the digital object from a data memory.

Preferably the apparatus is configured to process digital objects in an 10 MPEG format.

Preferably the multiplexer is configured to output an encrypted digital object which comprises packets of variable length.

The data type separator is preferably configured to output streams of variable length packets.

15 According to a third aspect of the invention there is provided an encrypted digital object which has been encrypted by the apparatus of the second aspect of the invention.

According to a fourth aspect of the invention there is provided a machine readable data carrier which, when loaded onto a data processor, causes 20 the data processor to implement the method of the first aspect of the invention. According to a fifth aspect of the invention there is provided a method of decrypting an encrypted digital object, the encrypted digital object

comprising a plurality of packets of data, the method comprising separating the encrypted digital object into respective streams of multiple packets of particular data types, decrypting at least some data of at least one data type in blocks of a predetermined size and then combining the 5 streams of data types in a decrypted digital object.

According to a sixth aspect of the invention there is provided apparatus for decrypting an encrypted digital object, the apparatus comprising a data type separator, a plurality of decrypters, each being configured to decrypt a particular data type, and a multiplexer, the apparatus being 10 such that in use, an encrypted digital object comprising multiple data types is input into the data type separator, the data type separator being operative to separate out the data types into respective data streams and input each data stream into a respective decrypter, the decrypters being operative to decrypt at least some of at least one data type in blocks of a 15 predetermined size, and the multiplexer being operative to combine the data streams which issue from the decrypters into an decrypted digital object. By using separate encryption modules for the audio, video and data streams it is possible to selectively encrypt one or more of the streams.

20 This provides tremendous flexibility, and is a significant improvement over technologies built upon a TS (Transport Stream) encryption model.

According to a seventh aspect of the invention there is provided an decrypted digital object which has been decrypted by the apparatus of the sixth aspect of the invention.

25 According to an eighth aspect of the invention there is provided a machine readable data carrier which when loaded onto a data processor,

causes the data processor to implement the method of the fifth aspect of the invention.

According to a ninth aspect of the invention there is provided a digital object comprising a plurality of packets of data and an encryption tag, 5 the packets of data forming respective streams of particular data types, at least some data of at least one data type being encrypted, the encryption tag being provided as a particular data type and said encryption tag being indicative of a location of the encrypted data within a respective stream.

The encryption tag is preferably provided at the head or the tail of the 10 digital object.

Preferably the encryption tag is provided as a block of Private Data, and at least one of a visual data stream and an audio data stream comprises encrypted data. The encryption tag preferably comprises an MPEG Private_Data_Stream_1 block. Preferably only a portion of at least one 15 data type is encrypted.

Particular portions of encrypted data may be encrypted with respective encryption keys.

The encryption tag is preferably indicative of which portions of data are encrypted and which portions of data are unencrypted.

20 The digital object is preferably in an MPEG standard format.

The encryption tag is desirably indicative of which data types and encrypted.

- -. - According to a tenth aspect of the invention there is provided a method of decrypting a digital object, the digital object comprising a plurality of packets of data and an encryption tag, the packets of data forming respective streams of particular data types, at least some data of at least 5 one data type being encrypted, the encryption tag being provided as a particular data type and said encryption tag being indicative of the location of the encrypted data within a respective stream, the method comprising separating the digital object into respective streams of the particular data types, processing the encryption tag and causing the 10 encrypted data to be input in a decrypter and causing unencrypted data to bypass a respective decrypter.

The method may comprise decrypting different portions of encrypted data with respective keys.

The method preferably comprises inputting decrypted data, and 15 unencrypted data which has been caused to bypass a respective decrypter, into a multiplexer.

According to an eleventh aspect of the invention there is provided apparatus which is configured to implement the method in accordance with the tenth aspect of the invention.

20 According to a twelfth aspect of the invention a machine readable data carrier which when loaded into a data processor is operative to implement the method in accordance with the tenth aspect of the invention. According to a thirteenth aspect of the invention there is provided a 25 method of decrypting a digital object, the digital object comprising a plurality of packets of data, the packets of data forming respective

streams of particular data types, at least some data of at least one data type being encrypted, the method comprising locating an unencrypted header and determining the location of the header within a respective stream so as to determine a location within a sequence of numbers used 5 to encrypt data which corresponds to a start location within a data stream from which decryption is to begin.

The method preferably comprises determining a seed value within the sequence of numbers used to encrypt data.

Preferably the method comprises synchronizing the decryption process 10 from a start location with the sequence of numbers used to encrypt the data. Preferably the method comprises locating a PICTURE_START_CODE of an MPEG video stream.

The method may comprise locating a SYNCWORD of an MPEG audio 15 stream.

Preferably the method comprises performing a pseudo-reset operation wherein the decryption process is reset to a particular value of the sequence of numbers used to encrypt the data.

According to a fourteenth aspect of the invention there is provided 20 apparatus which is configured to implement the method of the thirteenth aspect of the invention.

According to a fifteenth aspect of the invention there is provided a machine readable data carrier which when loaded onto a data processor is

operative to implement the method of the thirteenth aspect of the invention. In a preferred embodiment an initial portion of video is unencrypted stream and a subsequent portion of the video is unencrypted stream. In 5 order for a viewer to view decrypted content a password or other suitable credential needs to be entered, so as to enable a decryption key.

Preferably control information in the header section is not encrypted.

Thus in a preferred embodiment only actual video and audio information and any stuffing bits are changed by the described method. The digital 10 object maintains all MPEG standards even when encrypted and all header blocks and stream descriptions are left intact. Thus an encrypted file

will open using any proprietary MPEG1 player and attempt to play, but will produce no pictures and unrecognizable, if any, sound. Thus the information content of an MPEG data object (be it a stream or a static 15 file) is encrypted, without corrupting or otherwise altering the headers of the digital object, and therefore it can still be delivered through systems not "aware" of the inventive encryption system, without the risk of delivery errors occurring.

Since the headers are not encrypted, and therefore the basic structure of 20 the original combined stream is preserved, in a preferred embodiment this results in the decoders being able to play the audio content, without having errors triggered by trying to synchronise with the (encrypted) video content.

Preferably the data type streams are combined subsequent to encryption.

25 In a highly preferred embodiment a multiplexer combines the streams into a single MPEG Program Stream or System Stream (whichever is applicable for the MPEG version being encrypted).

Various embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: Figure 1 shows a schematic representation the hierarchy of MPEG encoded video data, 5 Figure 2 shows a block diagram of a process of encrypting an MPEG file in accordance with the invention, Figure 3 shows a block diagram of a process of decrypting the encrypted file resulting from the process of Figure 2, Figure 4 shows a modified arrangement to that shown in Figure 2, 10 Figure 5 is a schematic representation of a combined stream incorporating a portion of encrypted data, and Figure 6 is a schematic representation of two 'paired streams' which form the combined stream of Figure 5.

With reference to Figure 1 the basic structure of the MPEG-1 standard 15 will be explained. As is well known to those in the art video, audio and private data are encoded into a so-called System Stream which contains zero or more PES streams, and zero or more metadata/control streams.

Each PES stream contains packetised data corresponding to each of the video, audio and private data.

20 Video PES Streams are defined by ISO/IEC 11172-2. Such streams are also constructed using a hierarchical model.

This hierarchy consists of Sequence (topmost layer) 1 Group of Pictures (GOP) 3 Picture 5 5 Slice 7 Macroblock 9 Block (bottom most layer) 11 The Sequence, GOP, Picture and Slice layers use 'headers' 2, 4, 6 and 8 that consist of 'start codes' (32-bit tags) to identify their starting 10 positions which the Video PES Stream, and other coded information related to that layer. Macroblock and Block layers 9 and 11 do not use header 10 in the same way, and hence are not considered to form part of the control structure for decoding of the file.

The bottom most layer of the 11172-2 hierarchy is the Block 11. A 15 Block is an 8-row by 8-column orthogonal block of pixels. Groups of Blocks are grouped into Macroblacks 9, consisting of the four 8-by-8 Blocks of luminance data and the two corresponding 8-by-8 Blocks of chrominance data coming from a 16-by-16 section of the luminance component of the picture. Macroblocks are grouped together according 20 to their vertical position with a picture to form Slices 7. A slice represents a sequential series of Macroblocks, and is one of the layers of the coding syntax defined by 11172-2.

Slices are grouped together to construct a Picture 5 - a layer in the 11172-2 coding syntax used to represent an entire video frame (or 25 possibly field, if the content is interlaced). Pictures are typically

grouped together to form Groups of Pictures 3 (GOP's). GOP's are, in

fact, an optional coding syntax layer, and may be disregarded. If GOP's are present, they are grouped together to form a Sequence 1. If GOP's are not present, Pictures are grouped together to form a Sequence directly. Sequences are the highest layer of coding syntax defined by 5 11172-2.

Every layer of coding syntax contains both a header and a payload.

Some layers (e.g. Sequence, Picture) may contain multiple optional header extensions.

Each sequence 1 is a packet with a header 2 and a payload in the form of 10 GOP's 3. Similarly' each GOP 3 can be thought of as a sub-packet having a header 4 and a payload in the form of Pictures 5. Each Picture 5 can also be thought of as a sub-packet having a header 6 and a payload 7. Similar considerations are applicable to the slices 7 and the Macroblocks 9.

15 ISO/IEC 11172-3 defines the format of audio data for MPEG-1 and does not have a hierarchy in the same sense as 11172-2 (MPEG-1 Video).

Instead, it consists of a sequence of Frames which form an Audio PES Stream. A Frame contains a Header, an optional Error Check block, Audio Data (payload), and optional Ancillary Data. The headers start 20 with socalled 'Syncwords' that are not duplicated within the data content of the Audio PES Stream and are used as control markers for the decoding of the audio data.

Private Data PES Streams are undefined by ISO, and are left to the individual's discretion (but are subject to certain content and format 25 restrictions as laid down by ISO/IEC 11172-1/13818-1).

As is well known in the art each packet (the sequence in the case of video) of each PES Stream is of variable overall size, but is typically between 2048 to 65541 bytes.

The apparatus shown in Figure 2 comprises a stream splitter 14, a video 5 encryptor 15, an audio encryptor 16, and a multiplexer 17. Separate encryption modules are present for each data type since each requires a unique method of processing.

It will be appreciated that representation of the modules as physically separate entities is essentially schematic and the functions of each module 10 would typically be conducted by respective program coding acting on a single data processor unit (for example in the case of a PC). It would, of course, be possible to provide physically separate modules.

With reference to Figure 2 the encryption process is implemented in the following way (the example given is for MPEG-1, but the same process 15 is used for MPEG-2 and MPEG-4 content) An MPEG System Stream is read into memory buffers at 13 and stored as RBS.MPG.

The memory buffers are then parsed by a Stream Splitter 14, which separates out the audio, video and private data content into separate 20 streams. (For the sake of simplicity Figure 2 only takes account of video and audio streams). As is known to those skilled in the art a stream splitter acts to 'pull' or retrieve data from memory locations.

The streams are input into the respective Encryption Modules. The Encryption Modules 15 and 16 receive streamed data of the appropriate 25 type from the Stream Splitter 14 and encrypts data as it receives it.

T

As a result of the Slice being a layer in the coding syntax for 11172-2, it is required to have both a header and a payload. In fact, the Slice is the lowest coding layer. Since the Slice layer is the lowest coding layer, the encryptor 15 encrypts data at the Slice level and below. The Slice header 5 is left untouched - otherwise traditional decoders would be unable to process the stream - only the payload is encrypted.

The encryptor 15 encrypts Slice payload data in blocks of 32 bytes at a time in accordance with the AES encryption standard. If a Slice does not finish on a 32-byte boundary (ie. a whole number of encrypted blocks), 10 then data from the subsequent Slice is used to complete the encryption (and then, of course, the encrypted data is put back into the correct Slice). There are two exceptions to this process: i. The Slices are not from the same Picture (this is because the encryption system is reinitialised at the start of every Picture, so 15 that it is possible to seek within the video stream).

ii. The end of stream has been reached (no more data available).

In either instance mentioned above, one of two options are available to handle the situation: a. The unencrypted bytes left at the end of the slice can remain 20 unencrypted b. Additional 'padding' bytes can be added to complete the 32-byte block, so that the padding bytes and the slice data may be encrypted (but not any 'control data' in the header). A number of zero' (hex numeric OxOO) bytes is appended to the end of the 25 Slice. This conforms to the MPEG specifications for the

next_start code()' function, which will automatically skip leading zero bytes that occur immediately prior to a Start Code (including Slice Start Codes, which are contained in the first four byte positions of a Slice).

5 Obviously, whichever option is implemented, the encryption system has to match with the implementation in the decryption system, otherwise serious difficulties would arise.

As a result of this fact, the invention encrypts all data that occurs at the Slice layer or below (including Macroblock and Block layers), excluding 10 the Slice start codes. Slice start codes, and all information relating to higher' levels within the Video PES hierarchy, are not altered in any way. With regard to the audio PES Stream all data within each frame is encrypted by the encryptor 16, but not the frame header which remains 15 unaltered.

In fact, the audio encryptor 16 only encrypts the Audio Data (and Ancillary Data if present). The Audio and Ancillary data (henceforth referred to as the Audio Data Block) is encrypted by the invention 32 bytes at a time. If an Audio Data Block does not finish on a 32-byte 20 boundary (ie. a whole number of encrypted Audio Data Blocks), then one of two solutions is available: a. data from the subsequent Frame's Data Block is used to complete the encryption (and then, of course, the encrypted data us put back into the correct Data Block)

b. the unencrypted bytes left at the end of the Data Block remain unencrypted Obviously, whichever method is implemented, the encryption system has to match with the implementation in the decryption system, otherwise the 5 invention would not work.

Streams of encrypted data are then passed from the Encryption Modules 15 and 16 into a single Multiplex Module 17. The Multiplex Module 17 is configured to combine all of the separate Audio, Video and Private Data streams into a single Encrypted MPEG System Stream.

10 The Encrypted MPEG System Stream 24 is then either stored in a file or database as shown at 18, or broadcast as appropriate.

The decryption process shown in Figure 4 is effectively the reverse of the encryption process.

The Encrypted MPEG System Stream is read into memory buffers at 18.

15 The memory buffers are then parsed by a Stream Splitter 19, which separates out the audio, video and private data content into separate (encrypted) streams.

For each of the encrypted streams present in the Encrypted MPEG System Stream, a dedicated Decryption Module is used. (Separate 20 Decryption Modules exist for MPEG Audio data, MPEG Video data, and for MPEG Private data - this is because each data type requires a unique method of processing). The Decryption Modules 20 and 21 receive data of the appropriate type from the Stream Splitter, and decrypts data as it is received. Padding data is defined by the MPEG standards, so far as the decryption modules are concerned, it is treated like normal MPEG data,

and decrypted accordingly.

Decrypted data is then passed from all of the Decryption Modules into a single Multiplex Module 22. The Multiplex Module 22 is configured to 5 recombine all of the separate Audio, Video and Private Data streams into a single MPEG System Stream.

The MPEG System Stream is then either stored in a file or database as shown as 23, or broadcast as appropriate.

One unavoidable problem with the retention of the original header 10 structure (be it for video, audio or private data) is that it is impossible to determine whether the content is encrypted or not. This is down to a couple of factors: 1. MPEG data is very highly compressed. As a result, the actual content will look to be essentially random bytes of information.

15 2. The encryption process does not modify the size of the content in any way that could allow it to be identified as encrypted content.

As a result of those difficulties the above described encryption process creates a customised 'tag' that is attached to either the head or tail i. e. the beginning or end of a System/Program Stream, whether it is using 20 streamed delivery or machine-readable data carrier, e.g. CDROM of a piece of MPEG content, that explicitly marks that content as encrypted.

This 'tag' consists of an MPEG Private_Data_Stream_1 block, of variable length which contains a number of pieces of information, including a globally-unique identifier for that piece of content, as well as 25 identities that specify which of the contained streams (e.g. video stream,

- audio stream) of data are encrypted, and which ones (if any) are unencrypted. With reference to Figures 4, 5 and 6 show how the use of such encryption tags can be employed to form what may be termed as a 5 'paired stream construct'. Figure 5 shows a combined stream of a particular data type, say video data, in which a portion thereof (stream 2) has been encrypted with a particular encryption key. The encrypted portion or stream has a duration of two minutes. The encrypted portion is located between two unencrypted portions (stream 1). As seen best in 10 Figure 6 the combined stream can be considered as effectively comprising two streams, stream 1 which comprises the two temporally spaced portions of unencrypted data and stream 2 which comprises the portion of encrypted data. Associated with the combined stream is provided a Private Data Stream block which provides information of the 15 location of the encrypted portion in the combined stream.

With reference now to Figure 6 a digital object in MPEG format is input into a stream splitter 30. The stream splitter is operative to determine from the encryption tag in the Private Data Stream which portions of which streams are encrypted. As is shown, the stream splitter 30 is 20 operative input portions of encrypted data in each data type stream (eg stream 2) into respective decrypters 31 and 32 and input unencrypted data in each data type stream (e.g. stream 1) into the multiplexer 33 (and so by-passing the respective decrypters).

One can envisage a digital object in which portions of the data types are 25 encrypted with respective keys and so one may advantageously control access to some/all of the video data and/or some/all of the audio data.

As Figure 3 demonstrates, it is possible for the encrypted media to be decrypted back to a static file. For most applications this is not appropriate, however. It is often the case that the encryption has been used to protect the content from piracy and unlawful distribution. If a 5 pirate were to distribute the encrypted file, it would be impossible for anybody to view the content without a valid decrypt key. However, if a decrypted file were able to be produced, then the pirate would have an easy target.

As a result the present invention is fully capable of 'Just-In-Time 10 decryption. This is a process whereby, when decrypting the content the Decrypt Modules deliver the unencrypted content to an appropriate MPEG decoding/rendering device (for audio, this could be a sound card in your PC - video could be delivered to the monitor). In this way, no decrypted copy of the content ever exists in its entirety, making the task 15 of pirating the content extremely difficult.

When dealing with digital audio-visual content, it is often necessary to provide the ability to seek to random points in that content - typically as a user-driven (and therefore essentially unpredictable) event.

The problem with random-access of encrypted content is knowing at what 20 point you are in the content, so that you can resynchronise the decryption mechanism. It is often the case that this is not possible, simply because there is not an accurate enough mechanism for determining the distance between the original and new locations.

The preferred embodiment of the invention eliminates this problem 25 entirely, by using existing recognisable unencrypted headers as synchronization markers within the MPEG stream and resynchronise the

decryption seed value with a known position within the encrypted content. When encrypting data, the effect is more complicated than just replacing a single byte with a different single byte - that would be trivial to hack 5 and accordingly a very large sequence of numbers are generated by a mathematical algorithm - e.g. Rijndael. Then a 'key' is used to select the starting point ('seed value') within that sequence. Each number is used in turn on successive unencrypted bytes to encrypt them (e.g. some mathematical combination of the two numbers is generated).

10 The implication of this is that, if encrypted bytes are 'lost' (either due to problems in the transmission of the encrypted data, or if the encrypted data has been skipped intentionally, as would occur if trying to 'seek' for a particular time in the MPEG content), the decrypt sequence goes out-

of-step with the original encrypt sequence. This means that data cannot 15 be decrypted, and the system fails.

By using known points (in this case the headers for Picture objects, since pictures are the smallest reliably seekable unit in the MPEG hierarchy) to resynchronise the encryption process back to a known (or at least calculable) seed value, it is possible for the decryption process to do 20 likewise and guarantee that the encrypt and decrypt sequences remain synchronised. In Video PES Streams, PICTURE_START_CODEs are used as synchronization markers, whilst in Audio PES Streams, SYNCWORDS as synchronization markers. Both of these values are defined by the 25 relevant MPEG standards.

The synchronization markers trigger a 'pseudo-reset of the encryption process, so that decryption can continue in a known state whereby the seed value' for the encryption number sequence (as discussed prior) is reset to a known or externally calculable value. A known state is 5 achieved by setting the decryption process 'back' to a suitable point in its decryption number sequence, so that the current stream data may be decrypted correctly. The markers do not compromise the security of the encryption in any way, and have no impact on the MPEG decoding system whatsoever.

10 In order to make use of synchronization markers possible, it is necessary to either: 1. Pad the locations immediately prior to the synchronization markers with discardable data, so that the encryption can start afresh on a properly aligned data block, or 15 2. Leave the last few (up to 31, since the AES implementation being used relies on 32-byte blocks of data being encrypted at a time) bytes of data prior to the synchronization marker unencrypted - this does not have a measurable impact on the effectiveness of the security of the content, since 31 bytes does not represent a complete block of 20 information for either audio or video.

Claims (1)

1. A method of encrypting a digital object, the digital object comprising a plurality of packets of data, the method comprising separating the digital object into respective streams of multiple packets of 5 particular data types, encrypting at least some data of at least one data type in blocks of a predetermined size and then combining the streams of data types into an encrypted digital object.

2. A method as claimed in claim 1 in which the data types comprise at least one of data representative of visual material, audio material and 10 private material.

3. A method as claimed in claim 2 in which the data representative of visual material is most preferably representative of video material.

4. A method as claimed in any preceding claim which comprises combining the streams of data types into an encrypted data stream.

15 5. A method as claimed in any preceding claim which comprises selectively encrypting at least one particular data type.

6. A method as claimed in claim 4 which comprises selectively encrypting at least some data of at least some of the packets of at least one particular data type.

20 7. A method as claimed in any preceding claim which comprises retrieving the digital object from a memory buffer.

8. A method as claimed in any preceding claim which comprises encrypting a digital object which is in an MPEG format.

: - 9. A method as claimed in claim 1 in which data is encrypted in accordance with the AES (Advanced Encryption Standard).

10. A method of encrypting a digital object as claimed in claim 1 which comprises arranging that subsequent to encryption the digital object 5 comprises a plurality of least partially encrypted packets of variable length. 11. A method as claimed in claim 10 in which the digital object comprises multiple packets of variable length, each packet comprising a header and a payload, the payload of each packet comprises a plurality of 10 sub-packets, each sub-packet comprising a header and a payload, and only some of the sub-packets are encrypted.

12. A method as claimed in claim 11 in which the sub-packets represent hierarchical layers of video material in an MPEG standard, and the method comprises encrypting data at the Slice Level and below.

15 13. A method as claimed in any of claims 10 or 11 in which if the size of the data to be encrypted is not an integer multiple of the predetermined block size, additional data from another packet, or data from another sub-packet of the packet is added to the data to be encrypted to form a combined data block, the combined data block then 20 being encrypted.

14. A method as claimed in claim 13 in which the encrypted additional data is then returned to its originating packet or sub-packet.

15. A method as claimed in claim 10 or 11 in which if the size of the data to be encrypted is not an integer multiple of the predetermined block

1 _ size the data is encrypted with stuffing data, the stuffing data being appended to a payload of a packet or a sub-packet.

16. A method as claimed in claim 15 which comprises appending at least hex numeric OxOO bytes.

5 17. A method as claimed in claim 16 which comprises appending stuffing data to the end of a Slice of MPEG video data.

18. A method as claimed in claim 10 or 11 in which if the size of the data to be encrypted is not an integer multiple of the predetermined block size, data which is in excess of an integer multiple of the predetermined 10 block size is left unencrypted.

19. A method as claimed in any preceding claim in which the digital object is in a format which is suitable for use in relatively error free environments. 20. A method as claimed in claim 19 in which the digital object 15 comprises a plurality of Packetised Elementary Stream Packets.

21. A method as claimed in claim 10 or 11 in which data locations prior to at least some of the headers are provided with padding data such that encryption of data subsequent to the headers starts on an integer multiple of the predetermined block size.

20 22. A method as claimed in claim 10 or 11 in which the method comprises leaving some of the data prior to the headers unencrypted.

23. Apparatus for encrypting a digital object, the apparatus comprising a data type separator, a plurality of encryptors each being configured to

encrypt a particular data type, and a multiplexer, the arrangement of the apparatus being such that, in use, a digital object comprising multiple data types is input into the data type separator, the data type separator being configured to separate out the data types into respective data 5 streams and input each data stream into a respective encryptor, the encryptors being operative to encrypt at least some data of at least one data type in blocks of a predetermined size, and the multiplexer being operative to combine the data streams which issue from the encryptors into an encrypted digital object.

10 24. Apparatus as claimed in claim 23 in which the data type separator comprises a stream splitter which is operative to retrieve the digital object from a data memory.

25. Apparatus as claimed in claim 23 is configured to process digital objects in an MPEG format.

15 26. Apparatus as claimed in any of claim 23 in which the multiplexer is configured to output an encrypted digital object which comprises packets of variable length.

27. Apparatus as claimed in claim 23 in which the data type separator is configured to output streams of variable length packets.

20 28. Apparatus as claimed in claim 20 which is configured to implement the method of any of claims 1 to 21.

29. An encrypted digital object which has been encrypted by the apparatus as claimed in claim 23.

- 30. A machine readable data carrier which, when loaded onto a data processor, causes the data processor to implement the method as claimed in claim 1.

31. A method of decrypting an encrypted digital object, the encrypted 5 digital object comprising a plurality of packets of data, the method comprising separating the encrypted digital object into respective streams of multiple packets of particular data types, decrypting at least some data of at least one data type in blocks of a predetermined size and then combining the streams of data types in a decrypted digital object.

10 32. Apparatus for decrypting an encrypted digital object, the apparatus comprising a data type separator, a plurality of decrypters, each being configured to decrypt a particular data type, and a multiplexer, the apparatus being such that in use, an encrypted digital object comprising multiple data types is input into the data type separator, the data type 15 separator being operative to separate out the data types into respective data streams and input each data stream into a respective decrypter, the decrypters being operative to decrypt at least some of at least one data type in blocks of a predetermined size, and the multiplexer being operative to combine the data streams which issue from the decrypters 20 into an decrypted digital object.

33. A decrypted digital object which has been decrypted by the apparatus as claimed in claim 32.

34. A machine readable data carrier which, when loaded onto a data processor, causes the data processor to implement the method as claimed 25 in claim 31.

35. A digital object comprising a plurality of packets of data and an encryption tag, the packets of data forming respective streams of particular data types, at least some data of at least one data type being encrypted, the encryption tag being provided as one particular data type 5 and said encryption tag being indicative of a location of the encrypted data within the respective stream.

36. A digital object as claimed in claim 35 in which the encryption tag is provided at the head or the tail of the digital object.

37. A digital object as claimed in claim 35 or claim 36 in which the 10 encryption tag is provided as a block of Private Data, and at least one of a visual data stream and an audio data stream comprises encrypted data.

38. A digital object as claimed in claim 37 in which the encryption tag comprises an MPEG Private Data Stream 1 block.

39. A digital object as claimed in any of claims 34 to 38 in which only a 15 portion of at least one data type is encrypted.

40. A digital object as claimed in any of claims 35 to 39 in which particular portions of encrypted data are encrypted with respective encryption keys.

41. A digital object as claims in any of claims 35 to 40 in which the 20 encryption tag is indicative of which portions of data are unencrypted.

42. A digital object as claimed in any of claims 35 to 41 in which the encryption tag is indicative of which data types are encrypted.

43. A digital object as claimed in any of claims 35 to 42 in which the digital object is in an MPEG standard format.

44. A method of decrypting a digital object, the digital object comprising a plurality of packets of data and an encryption tag, the 5 packets of data forming respective streams of particular data types, at least some data of at least one data type being encrypted, the encryption tag being provided as a particular data type and said encryption tag being indicative of the location of the encrypted data within a respective stream, the method comprising separating the digital object into 10 respective streams of the particular data types, processing the encryption tag and causing the encrypted data to be input in a decrypter and causing unencrypted data to bypass a respective decrypter.

45. A method as claimed in claim 44 which comprises decrypting different portions of encrypted data with respective keys.

15 46. A method as claimed in claim 44 or claim 45 which comprises inputting decrypted data, and unencrypted data which has been caused to bypass a respective decrypter, into a multiplexer.

47. Apparatus which is configured to implement the method as claimed in any of claims 44 to 46.

20 48. A machine readable data carrier which when loaded onto a data processor is operative to implement the method as claimed in any of claims 44 to 46.

49. A method of decrypting a digital object, the digital object comprising a plurality of packets of data, the packets of data forming 25 respective streams of particular data types, at least some data of at least

one data type being encrypted, the method comprising locating an unencrypted header and determining the location of the header within a respective stream so as to determine a location within a sequence of numbers used to encrypt data which corresponds to a start location within 5 a data stream from which decryption is to begin.

50. A method as claimed in claim 49 in which the method comprises synchronizing the decryption process from a start location with the sequence of numbers used to encrypt the data.

51. A method as claimed in any of claims 49 or 50 which comprises 10 locating a PICTURE_START_CODE of an MPEG Video stream.

52. A method as claimed in any of claims 49, 50 or 51 which comprises locating a SYNCWORD of an MPEG audio stream.

53. A method as claimed in any of claims 49 to 52 in which the method comprises performing a pseudo-reset operation wherein the decryption 15 process is reset to a particular value of the sequence of numbers originally used to encrypt the data.

54. Apparatus which is configured to implement the method as claimed in any of claims 49 to 53.

55. A machine readable data carrier which when loaded onto a data 20 processor is operative to implement the method of any of claims to 49 to 53.

56. A method of encrypting a digital object substantially as described and as shown in the accompanying drawings.

57. Apparatus for encrypting a digital object substantially as described and as shown in the accompanying drawings.

58. A method of decrypting a digital object substantially as described and as shown in the accompanying drawings.

5 59. Apparatus for decrypting a digital object substantially as described and as shown in the accompanying drawings.

60. A digital object substantially as hereinbefore described.