US20140189358A1 - Multimedia data protection - Google Patents

Multimedia data protection Download PDF

Info

Publication number
US20140189358A1
US20140189358A1 US14/109,888 US201314109888A US2014189358A1 US 20140189358 A1 US20140189358 A1 US 20140189358A1 US 201314109888 A US201314109888 A US 201314109888A US 2014189358 A1 US2014189358 A1 US 2014189358A1
Authority
US
United States
Prior art keywords
client
key
server
keys
viewer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/109,888
Inventor
Gisle Grimen
Christian Mönch
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Conax AS
Original Assignee
Conax AS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Conax AS filed Critical Conax AS
Priority to US14/109,888 priority Critical patent/US20140189358A1/en
Assigned to CONAX AS reassignment CONAX AS ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GRIMEN, GISLE, MÖNCH, Christian
Publication of US20140189358A1 publication Critical patent/US20140189358A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2347Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving video stream encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2389Multiplex stream processing, e.g. multiplex stream encrypting
    • H04N21/23895Multiplex stream processing, e.g. multiplex stream encrypting involving multiplex stream encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808Management of client data
    • H04N21/25816Management of client data involving client authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/26613Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel for generating or managing keys in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4385Multiplex stream processing, e.g. multiplex stream decrypting
    • H04N21/43853Multiplex stream processing, e.g. multiplex stream decrypting involving multiplex stream decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4405Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video stream decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44236Monitoring of piracy processes or activities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633Control signals issued by server directed to the network components or client
    • H04N21/6332Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H04N21/63345Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key by transmitting keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/167Systems rendering the television signal unintelligible and subsequently intelligible
    • H04N7/1675Providing digital key or authorisation information for generation or regeneration of the scrambling sequence

Definitions

  • the present invention relates to the secure distribution of multi-media works that have a temporal dimension such as movies, TV shows, audio documents, etc.
  • it relates to a system for securely delivering such works to a user in a manner that prevents the user from obtaining an unauthorized copy of the work.
  • aspects of the invention also have applications in other server-client situations such as on-line banking, gaming, etc.
  • a media work is downloaded, a copy of it is stored on the hard drive of the computer and it can normally be viewed repeatedly by the user, analogously to watching a video recording.
  • Streaming content is watched as it is transmitted to the computer (as with a conventional TV programme) in almost real-time (there is a short delay due to the need to provide some buffering). It is well known for radio and some TV stations to offer their content in this manner.
  • the media supplier who is referred to here as a “content provider”, owns encoded media works, for example movies, which will be referred to generically as “media works”. These are to be distributed and presented to a user's client program/viewer in a way that does not allow the user to create a copy of the encoded media work.
  • the delivery can be carried out by either streaming over a network or by delivering a physical medium, for example a DVD, to the client.
  • Encryption which is a security measure, is to be distinguished from encoding, whereby the work is converted and usually compressed into a form that can readily and efficiently be transmitted.
  • Encryption techniques are sufficiently well developed and secure that the communication over computer networks can be secured in an appropriate way.
  • the content owner protects the encoded media document using cryptographic means.
  • an encryption tool is used to encrypt the work with a “media key” to create an encrypted encoded media work, the “encrypted work”.
  • the intention is that the client can then only use the work if he has the media key that allows him to decrypt it.
  • This can be embedded in the client program/viewer/player and/or the media, for example in DVD-players and DVDs.
  • the client program/viewer/player may be a free-standing device or a viewer software program on a computer.
  • the media key is retrieved from a license server 1 on demand.
  • This allows for streaming of the media work.
  • the encryption tool 2 wraps the media key, together with additional information, in a license 3 and sends this to the license server 1 .
  • the client receives an encrypted, encoded media stream 4 from the streaming server 5 that has to be decrypted in a viewer 6 before it can be presented to the client.
  • the viewer requests a license containing the media key from the license server (see “Start-up Phase” in FIG. 1 ).
  • the viewer Once the viewer has received the license 3 (and therefore the media key), it connects to the streaming server 5 from which it receives an encrypted encoded media stream 4 .
  • the viewer uses the media key to decrypt the encrypted encoded media stream and present it to the client (see “Streaming phase” in FIG. 1 ).
  • a major problem in the scenario described above is that the viewer is executed on a host that is controlled by the client. Thus, the viewer is not executed in the trusted environment 8 (where the movie 9 was originally encrypted). There is, therefore, a risk that the client could modify the viewer. Even though the viewer will usually only decrypt and decode part of the media stream, during the whole presentation process every part of the encoded media stream will at some point be present in the viewer memory-image. Another risk is that, since the memory image of the viewer has to contain the key, the user could extract the media key, in which case he would be able to create a copy of the unencrypted encoded media.
  • a media work is a work that has a temporal aspect, i.e., it contains a number of presentational steps that have to be performed in an appropriate order.
  • the steps are normally computationally independent of each other and can be processed independently. In most cases, the complete presentation takes a significant amount of time: many minutes or some hours in the case of a movie.
  • a method of transmitting a media work to a client comprising the steps of:
  • the invention may be applied to any kind of media work (as defined above) that has a temporal aspect, and is particularly useful for distributing movies, for example streaming them over the Internet.
  • each key can decrypt only one segment, i.e., the keys are functionally independent.
  • the keys should preferably be structurally independent.
  • thousands of different keys are used for a typical length of film such that each corresponds to a segment of a pre-determined length, e.g., of only a few seconds, say less than two or three seconds, and most preferably a second or less.
  • Most kinds of media works only have significant value if they are substantially complete. For example, a movie with only the last few minutes missing will usually be of little value. Thus, someone seeking to illicitly copy a movie will have to decrypt each of the segments.
  • the client may ask for the current key and the next key(s) and cache a small number of keys (e.g., 2, 3, 4 or so) in memory.
  • a small number of keys e.g., 2, 3, 4 or so
  • the secure server is remote from the viewer, and is referred to herein as a ‘security server’.
  • the movie is generally encrypted in a trusted environment.
  • the keys generated during encryption are supplied to the security server, which is within the trusted provider environment.
  • the keys are then transmitted from the security server to the viewer, the movie or other work may be transmitted from elsewhere. For example, it may be streamed from a separate server that is outside the trusted environment. Therefore, in one preferred embodiment, once the movie has been encrypted in the trusted provider environment, it is then supplied to a non-secure streaming server.
  • the client which may be a software viewer program running on a remote computer (e.g., a user's PC) communicates with a security server to receive the keys (referred to as media keys) and with a separate streaming server.
  • a security server to receive the keys (referred to as media keys) and with a separate streaming server.
  • the media keys are preferably transmitted to the client following a request from the client, and this is preferably done using a key exchange protocol that makes use of a random data generator and the public key of the security server, which is known to the viewer.
  • the client when it is necessary to obtain the next media key, the client generates random data and encrypts it with the public key of the security server.
  • the encrypted data may then be included in a request for the next media key, preferably with data identifying the client, which is sent to the security server.
  • the security server checks whether that client is entitled to receive the media work, decrypts and extracts the random data and performs a function using it and the requested key, to encrypt the key using the random data. In one embodiment, they may be XOR'ed. The result is then sent back to the client.
  • the client When the client receives the result, it can then extract the requested key from the result by carrying out a corresponding function, for example by XORing it with the same random data that was provided in the original request for the key. In this way the encrypted, encoded media stream can be decrypted without any secret keys hidden in the source code of the viewer.
  • the public key is included in the checksum calculation in order to prevent a “man in the middle” attack in which the public key is exchanged.
  • steps are also taken to ensure that the client checked by the mobile guard is the same one as the one generating the random data. This may be done by extending the input to the checksum to include the random data used to request the media key.
  • the input to the checksum may include code from the client, the public key of the security server and the random data sent with the key request.
  • the entropy source used for generating the random numbers may be that generated by the executing environment itself in the form of how tasks are scheduled and interrupted.
  • the random generation process may consist of creating several threads that work on different computational tasks that can be input into a secure hash algorithm along with data from the current state of the viewer and the executing mobile guard.
  • the need for a continuing sequence of keys to be received by the client can be used to enforce user co-operation.
  • this step may be an integrity check of the client, and preferably, the request for a new key is only responded to when a so-called “mobile guard” indicates that the viewer is unmodified.
  • the mobile guard is employed, it is possible for it to generate the random number used in the preferred key exchange protocol described above, rather than the actual client viewer/player program.
  • the trusted environment is extended so that the streaming server is included within it.
  • the streaming server generate media keys and encrypt the media stream on the fly. This ensures that each media stream is encrypted with a unique set of media keys. That means that a leaked media key cannot be used to decrypt a different copy of the same movie.
  • the streaming server sends them to the security server, which will distribute them to the viewer as described above.
  • the downside is that another entity needs to be trusted and that the encryption on the fly is computationally expensive. Thus, there is a trade off here between very high security on the one side and complexity of the trusted environment and computational costs on the other side.
  • the invention is not limited to arrangements where the document is streamed from a remote server. Because it is encrypted, the document can be distributed in any convenient manner. Thus, the encrypted document may be provided to the client from a local server or on a physical medium (e.g., a DVD). The document may then be transmitted from the local server or physical medium to the viewer and decrypted in the same manner as previously discussed.
  • a local server or on a physical medium (e.g., a DVD).
  • the document may then be transmitted from the local server or physical medium to the viewer and decrypted in the same manner as previously discussed.
  • the invention further comprises means for checking the integrity of the viewer to ensure that it has not been tampered with. This may be done by programming it to send a signal such as a checksum to the security server at regular intervals, and/or when a key is requested. Such a signal would be designed to depend on the state of the viewer so that any modification to the viewer would change the signal.
  • the method further requires that the security server interrogate the viewer using a number of different tests, which vary with time.
  • the tests comprise the use of randomly generated algorithms which will only return the correct result if the viewer is unmodified.
  • failure to respond or an undue delay in responding can be taken as an indication of viewer modification.
  • the security server is arranged to cease the supply of keys in the event that viewer modification is detected and/or if such a viewer integrity check is not successful.
  • the most preferred arrangement is for the algorithms to be transmitted by the security server to the client in the form of software code (e.g., machine code).
  • the software code may be termed a “mobile guard”, and is described further herein.
  • Such a system of integrity checking is considered to be an inventive concept in its own right and therefore, viewed from a further aspect, there is provided a method of transmitting data to a client comprising the steps of:
  • the data may be a media work that is streamed to the client, for example over the Internet, or it can be supplied from a local server, DVD or other media as discussed above. However, as will be discussed more fully below, it may be any kind of data that can be transmitted between server and client.
  • the client may be a program running on a computer or a hardware device such as a TV set-top box.
  • the algorithm referred to in step (b) may be transmitted before any part of the document has been transmitted, or the whole or part of the work may be transmitted before the algorithm. Preferably, the document is not viewed until after step (d) has been carried out.
  • step (d) appropriate action can be taken.
  • the transmission of the work and of any keys required to decrypt it would normally be allowed to continue.
  • step (e) there may be a further step of (e) ceasing the transmission of the work and/or of keys necessary to decrypt it in the event that the result is not indicative of an unmodified client.
  • this is also deemed to indicate that the client has been modified.
  • the action may be to cease the transmission of the keys needed to decrypt the document.
  • the transmission could be allowed to continue and evidence gathered to identify the user. This may be appropriate if it is desired to take legal or investigative action, e.g., to detect criminal activity or to prevent future illicit copying of documents.
  • the action taken in response to the identification of a modified client may be to cease transmission of decryption keys.
  • the method may further comprise dividing the work into a plurality of temporally spaced segments, which are encrypted using different keys. These keys may be distributed to the client sequentially, and preferably as discussed above. Thus, if their distribution is ceased, the remaining part of the work cannot be decrypted.
  • the method is preferably carried out using randomly generated secret algorithms in the software code (as mentioned above). These so-called enforcement algorithms generate a result that is dependent on the state of the client (e.g., of a viewer program), but the correct result is not guessable by the user because of the random aspect.
  • they contain a checksum calculation into which the viewer program's code is input.
  • the checksum calculation may be a known one such as the Message Digest Algorithm 5 (MD5) (RFC1321 www.faqs.org/rfcs/rfc1321.html), which may be used in combination with randomized input modification.
  • Input modification refers to the random creation of a modifier that permutates the data that will be input into the checksum.
  • a mobile guard when the software code (referred to here as a “mobile guard”) is generated, a random sequence is determined.
  • the algorithm is executed, the input code from the viewer is divided into n blocks of the same size. These are then shuffled into the above-mentioned random sequence and the result is then input into the checksum algorithm.
  • the checksum algorithm itself is public, its result is a function of the order in which the n blocks are input to it. This order is known to the security server and so the security server can determine whether the result returned to it indicates an intact viewer.
  • An alternative approach to creating an input-filtered checksum is to decompose a known checksum algorithm and reassemble it in a way that reads the input in a given sequence.
  • the input can be split into/words (32 bits) and a function f is created that reads/words from the input and m words from a variable area that outputs a word.
  • the function may comprise a random number of assignments that are performed one after another and the checksum may be the sum modulo 2 32 of all the results of the application off.
  • Composing functions has the advantage that almost all code of the checksum algorithm is randomly created, leading to more structural diversity in the code. Since the building blocks are quite small, it allows for easier interleaving with other algorithms.
  • the software code also preferably contains additional algorithms, which may be secret or non-secret. They are preferably functionally and/or spatially entangled with the secret algorithm. In this way the client's computer/viewer can be forced to carry out the additional algorithms because if it does not the secret one will not be implemented.
  • the additional algorithms may be used, for example, to check the integrity of viewer hardware.
  • the mobile guard As the mobile guard is present in the same environment as the viewer, it is potentially vulnerable to attacks. A user might try to modify it in order to circumvent the protection methods it implements. Automated attacks on it can be prevented by ensuring that the mobile guards are partly randomly created, as discussed above. In addition, obfuscation transformations may be applied to the mobile guards.
  • the mobile guard may hide the checksum in an opaque data structure that is interleaved with the checksum in a way that is specific to the mobile guard.
  • Variables may be located randomly in the mobile guard's memory and, in addition, the mobile guard's instructions may be split into blocks, which are also located randomly in memory. This preferably includes the entry point into the mobile guard. Indeed, the entry point for one mobile guard can be provided by the previous one.
  • the viewer is, therefore, preferably protected by the mobile guard against its state being determined by spying.
  • the mobile guard will preferably further comprise one or more protection algorithms to protect against such attacks.
  • This it may perform obfuscation tasks on the client (e.g., on a viewer program), referred to hereinbelow as “runtime viewer obfuscation”, i.e., obfuscation is carried out on the viewer as it runs. This changes the memory image of the running viewer.
  • This runtime viewer obfuscation is considered a further inventive concept, and thus from another aspect, the invention provides a method of obfuscating an executing viewer, comprising randomising the memory image of the executing viewer.
  • Runtime obfuscation may comprise one or more of the following techniques.
  • Code relocation comprises moving code blocks around in memory. As the program executes, the mobile guard will move the code to other parts of memory, which will then later be executed. This algorithm is preferably tightly interleaved with the checksum calculation.
  • code relocation is implemented by (1) identifying all the basic building blocks in the program and partitioning it into small relocatable segments; (2) during execution of the mobile guard these segments may be rearranged in memory to random locations; and (3) modifying all jump instructions to correspond to the new code locations.
  • code relocation is implemented by (1) identifying all the basic building blocks in the program and partitioning it into small relocatable segments; (2) during execution of the mobile guard these segments may be rearranged in memory to random locations; and (3) modifying all jump instructions to correspond to the new code locations.
  • Data relocation comprises moving the data and changing the instructions that access it. Again, the new locations can be determined randomly.
  • One approach is to apply a two-way function to alter the appearance of the data—effectively to mask it.
  • a simple one-time pad approach is used. It may comprise a newly created modulo function that creates an index into an array of random data.
  • the random data may be used to alter the sensitive data by applying the XOR operator between the random and sensitive parts. Preferably it is applied between these and part of the address of the sensitive data.
  • One approach is to scramble (mask) and unscramble the data so that sensitive data is stored in scrambled form, unscrambled when needed, and then re-scrambled or deleted. However, this does leave a short window when the data is unscrambled.
  • the actual content decoder may be modified to perform the last decryption operation, as it needs new data. This means that there will not be any decrypted data present in main memory at all. It may be provided using the following steps:
  • Code diversification comprises operations performed by the mobile guard on the client program during execution.
  • the operations performed change the code such that it consists of different instructions without changing its semantics. This is to prevent pattern-based identification.
  • One or more of the following steps may be carried out:
  • Context-independent instructions may be inserted. These are instructions whose input context may be shared with contexts in the program but whose output context is different from any input context in the program. Since they cannot alter any input context of the program, it does not matter what they process.
  • Context dependent instructions may be replaced by instructions that perform the same function. It will be appreciated that this is more difficult to achieve, but it is also more effective because they cannot be identified by data-flow analysis.
  • Functional independent changes that can be made include changing the order of execution of instructions, inserting instructions with or without temporary variables, re-ordering instructions in memory and making control flow changes.
  • Functional dependent changes require care in order to keep the function and side effects intact. They include replacing instructions with functional equivalents, introducing identity functions, introducing operators so that literal values are replaced by instructions that initialise the value arbitrarily and perform an operation that corrects the value to match the original literal. Also, variables can be introduced so that copies to a destination are replaced by copies of a newly created variable.
  • a hardware-based viewer solution for example a TV set-top box
  • the distributor of the viewer controls not only the viewer software, but also the viewer environment, i.e., the hardware and operating system. Therefore, a hardware based viewer can generally be checked by a mobile guard in a much more complete manner than a purely software based solution.
  • the checksum algorithm in the mobile guard is not restricted to checking the viewer software but can also check different aspects of the operating system and the hardware.
  • the system can be used in two ways in connection with hardware-based viewers. Firstly, it can be used to replace solutions that are based on expensive tamper-proof hardware. Secondly, it can provide additional security measures that come into play in the event that the tamper-proof hardware should be compromised.
  • the invention preferably relates to the combination of individually encrypted segments of the document and the use of the “mobile guard” concept.
  • the invention provides a method of transmitting a media work to a client comprising the steps of:
  • step (e) may be carried out concurrently with steps (b), (c), (d) or (f), such that the segments are transported before, with or after the keys. However the keys must be available before the segment is decrypted.
  • the method comprises a further step (h) wherein steps (b) to (g) are repeated.
  • the transmitted software code has a certain ‘lifetime’ or ‘trust interval’, for example less than 30 seconds.
  • segments are generally transmitted more frequently than the lifetime of the software code, for example one per second.
  • new software code does not need to be transmitted each time a segment is transmitted, but will generally only need to be transmitted once the lifetime of the present software code has expired.
  • steps (e) to (g) will generally be repeated until new software code is required, when step (b) will be repeated. In this way one piece of software code (mobile guard) protects the delivery of many keys.
  • steps c and d can be done more than once for each piece of software code, generally, it will only be necessary to do it once during the lifetime of the software code. As such, steps (c) and (d) will generally only be repeated after step (b) has been repeated.
  • the invention provides a method of transmitting a media work to a client comprising the steps of:
  • the method further comprises the step (i) of repeating steps (b) to (d).
  • Steps (b) to (d) can be carried out independently of steps (e) to (h), and are preferably carried out concurrently therewith.
  • the software code generally has a lifetime that will encompass the sending of many segments and keys.
  • the repetition of steps (b) to (d) (mentioned in step (i)) will generally be carried out less frequently than the repetition of steps (e) to (g) (mentioned in step (h)).
  • step (i) is only carried out if the lifetime of the software code has expired.
  • the invention also extends to apparatus configured to operate as discussed above, including a client configured to receive such streamed media and also the server arrangement, both in combination and separately.
  • a system for delivering a media work to a client comprising:
  • a client e.g., a viewer for playing a work such as a movie
  • the client being arranged to: receive the work and to receive software code containing an algorithm from a remote source; to execute the algorithm on the client; and to return a result of the algorithm to the remote source, thereby demonstrating the integrity of the client to the remote source and enabling the playing of the document.
  • the client preferably enables the playing of the work by decrypting it, or decrypting a segment of it using a key supplied to it by the remote source.
  • the client is configured to request a sequence of keys and uses the keys in sequence to decrypt consecutive sections of the work, which are then played as a continuous presentation.
  • the provision of keys is dependent on the client demonstrating its integrity to the source.
  • the invention also extends to a combination of a system for delivering works as described above, in combination with a client, whereby documents are delivered to the client and can only be played if the viewer demonstrates its integrity to the source.
  • the present invention does not rely on secrets that are contained in the data that is made available to the user, whether in the program code or in the media documents. It allows the early detection of copy attempts and allows the content provider to initiate counter-measures before a substantial part of the media document can be copied.
  • the invention comprises transmitting software code (such as a mobile guard) from a secure source to a client computer running a client program, the software code comprising an algorithm having a result that is dependent on the state of the client program, executing the software code and returning the result to the source, whereby the source can determine the integrity of the client program.
  • software code such as a mobile guard
  • the invention also extends to apparatus arranged to operate in accordance with such a method.
  • This aspect of the invention may employ any or all of the preferred features discussed above, in particular concerning the mobile guard.
  • References above to media works apply likewise to temporal payload data sent between server and client.
  • the service provider can enforce the cooperation of the user's client in the same manner and can withhold further payload data if either cooperation ceases or tampering is detected.
  • any client that is in communication with a server can have its integrity checked on an on-going basis.
  • the invention therefore allows a client that operates in an uncontrolled environment to be trusted. If it transpires that the integrity of a client has been compromised then action can be taken. For example, communication with the client could be terminated, the provision of decryption keys suspended (as with the media streaming applications discussed above) and/or steps taken to gather evidence (e.g., in the case of suspected fraudulent attacks on banking systems).
  • the invention is useful in the context of distributed calculations where, although confidentiality and dishonesty are not usually issues, the correct execution of software is.
  • the mobile guard may be used to protect against intentional or unintentional modification of the client—both its software and, if required, hardware.
  • the instance that launches the distributed computing job can use mobile guards to check the correct operation of the clients at remote nodes that carry out calculations.
  • mobile guards can be used to make sure that third parties do not access confidential data. While a normal user will not normally be interested in modifying his client program, he may be the victim of a man-in-the-middle attack.
  • the banking server could therefore use a mobile guard to verify the integrity and authenticity of the home banking client and it may also contain the public key of the banking server. This public key is used to encrypt all data that is passed from the home banking client to the banking server and since the integrity of the mobile guard is guaranteed, the user can be sure that his data is kept confidential.
  • FIG. 1 is a schematic drawing of a prior art media streaming system as described above;
  • FIG. 2 is a schematic overview of a first embodiment of the invention
  • FIG. 3 is a schematic diagram showing the components of a randomly generated checksum algorithm as used in the embodiment
  • FIG. 4 is a flow chart showing the operation of the embodiment.
  • FIG. 5 is a flow chart of the server algorithm employed in the embodiment.
  • a client is provided with a viewer 10 which can be used to view media (e.g., a movie) that is streamed from a streaming server 11 or alternatively from a local storage media, e.g., CD 12 .
  • media e.g., a movie
  • CD 12 a local storage media
  • Each of these components of the system is outside the trusted environment 13 .
  • the unencrypted movie 14 Within the trusted environment is the unencrypted movie 14 , a protection tool 15 to generate a protected movie 16 and a security server 17 .
  • protection tool 15 encrypts the movie with a very large number (thousands) of media keys 20 . This process yields an encrypted, encoded media, the protected movie 16 .
  • the media keys 20 are distributed so that they are spread out in time; during presentation of a media resource, they are securely streamed to the client one at a time at intervals on request as will be described below.
  • the media itself is streamed separately.
  • Each key comprises only a few bytes (about sixteen) so the resources needed to stream the keys create a very low overhead.
  • Each key can be used to decrypt only about a second, or at most a few seconds, of the movie so that obtaining only a single key is of little value.
  • the protected movie is delivered to the client in form of a data stream via path A, streaming server 11 and media stream 18 .
  • tangible media e.g., a CD or DVD 12 are used.
  • the viewer 10 is executed on the client's host and is arranged to receive the protected movie 16 from the streaming server 11 via media stream 18 (or from the CD/DVD in other embodiments).
  • the viewer 10 communicates with a security server 17 to download the necessary media keys 20 to decrypt the protected movie 16 .
  • the viewer 10 also downloads pieces of code called mobile guards 19 at regular intervals of about 30 seconds. These each have embedded within them secret information in the form of an algorithm that is created in the security server 17 . The execution of these algorithms is necessary to make use of the streamed data 18 .
  • each mobile guard 19 When each mobile guard 19 is transferred into the viewer it performs calculations determined by the secret algorithm and returns the result to the security server.
  • the mobile guard is structured in such a way that the result of the calculation is only correct if the viewer has not been tampered with.
  • the result of the secret algorithm contains a checksum that proves the integrity of the viewer to the security server.
  • the mobile guard can also have other additional algorithms functionally and spatially entangled with the secret algorithm. In this way the client's computer/viewer can be forced to carry out the additional algorithms because if it does not the secret one will not be implemented. In this way, the viewer may be fully checked.
  • the security server stops the distribution of the media keys 20 to the viewer. The same happens if the viewer 10 refuses a mobile guard or if the correct result does not arrive within a certain time.
  • the key exchange protocol will be explained in more detail later.
  • the secret algorithms are based on checksum calculations that have a high probability of detecting changes in the checked data (i.e., the viewer code).
  • a randomly generated checksum algorithm 21 uses a checksum calculation divided into two steps: input modification 22 , which is randomized, and a known checksum calculation 23 which is performed on the modified input. These steps together make the randomized and secret checksum algorithm.
  • Input modification refers to the random creation of a modifier that permutates the data that will be input into checksum calculation 23 .
  • a mobile guard is generated by the security server, a random sequence is determined.
  • the checksum algorithm 21 is executed by the viewer, the input Program Code from the viewer is divided into n blocks of the same size. These are then shuffled into the above-mentioned random sequence in the Input Modification stage 22 . The result of this is then input into the Checksum Calculation stage 23 . This uses the known Message Digest Algorithm (MD5). The checksum calculation is then carried out and its result returned to the security server.
  • MD5 Message Digest Algorithm
  • checksum algorithm itself is public, its result is a function of the order in which the n blocks are input to it. This order is known to the security server and so the security server can determine whether the result returned to it indicates an intact viewer.
  • the mobile guard needs to be protected against tampering and against the spying out of its inner workings.
  • the first aspect of the protection of the mobile guard is to randomly create new versions each time a viewer needs to be checked.
  • the lifetime of the mobile guard in the viewer environment when it is being used is short (less than thirty seconds).
  • the mobile guard is obfuscated, as previously discussed, to defend against an automated attack.
  • the mobile guard randomises the memory image of the running viewer, referred to herein as ‘runtime viewer obfuscation’. Code and data areas of the viewer are swapped and the stack is scrambled. This is discussed more fully below.
  • runtime viewer obfuscation The effect of runtime viewer obfuscation is to make sure that only intellectual attacks can be performed on the runtime image of the viewer because it randomises and thereby hides the memory locations of the decrypted, encoded stream.
  • the mobile guard modifies the structure of the viewer code and the data area.
  • the code and data area are split into logical segments. Care is taken that segment borders are not located inside opcodes.
  • the mobile guard After relocating the segments, the mobile guard performs its operation until it is replaced by the next mobile guard.
  • the mobile guard needs to know the entry points of certain functions in the viewer.
  • the new positions of the segments are known by the security server and provided to the mobile guard. In this way there is no need to transfer information between two mobile guards on the client side.
  • the stack contains the return addresses to prior function calls. This can be used to either spy out control flow or to alter the control flow of the viewer by changing a return address on the stack. In such an attack, when the program is about to jump back to the calling function, it could instead be transferring control to possible hostile code.
  • a method that gradually scrambles the stack as new return addresses are added to it.
  • the checked code will, after a function call, transfer control to a scramble function in the mobile guard, which scrambles the new return address on the stack before returning control back to the calling function.
  • To unscramble the stack a corresponding unscramble function in the mobile guard is called before using any return address.
  • the implementation of the scramble function takes advantage of the fact that mobile guards are created as needed in order to check the viewer. This enables a unique scramble and unscramble function to be created in each mobile guard.
  • the scramble function basically consists of a set of random data created by the security server and contained in the mobile guard that is XORed with the return addresses on the stack of the viewer. To select which part of the random data to use, a simple mathematical function is applied to compute an index into the set of random data.
  • the viewer is therefore protected by the mobile guard against its state (including the position of the control flow and variable content) being determined by spying (as discussed previously).
  • the media keys are transmitted at a rate of approximately one per second to the viewer. This is done using a key exchange protocol that makes use of a random data generator and the public key of the security server, which is known to the viewer. When it is necessary to obtain the next media key the viewer 10 generates sixteen bytes of random data and encrypts them with the public key of the security server 17 . The encrypted data is then included in a request for the key, which is sent to the security server.
  • the security server examines the request and only approves it if the mobile guard indicates that everything is correct in the viewer. If the mobile guard indicates that everything is fine, the security server extracts the random data, XOR's it with the requested key and sends the result back to the viewer.
  • the viewer When the viewer receives the result, it extracts the requested key from the result by XORing it with the same random data that was provided in the original request for the key.
  • This protocol provides a way to decrypt the encrypted, encoded media stream, without any secret keys hidden in the source code of the viewer.
  • the lifetime of a key is a only few seconds, which prevents the secure streaming process from constituting a single point of failure in the event of the extraction of one or a few secret keys.
  • the first thread is verification.
  • the client receives a mobile guard, which then verifies the client program. Once verification has been confirmed, a number n of keys can be received during the following trust interval until the mobile guard expires. The thread must then be repeated with a new mobile guard.
  • FIG. 5 summarises the operation of the server.
  • On receiving a key request it sends a key to the client if, and only if, the mobile guard is still alive (i.e., if it is still within the trust interval of that mobile guard). If the mobile guard has expired, a new mobile guard is sent to the client and this is used to verify the client. If the result is incorrect, the client is deemed to have been tampered with and key transmission is then stopped. If the result is satisfactory, then a new trust interval commences and during it the keys are sent to the client.

Abstract

A method of transmitting a media work such as a movie to a client is disclosed. The method includes (a) encrypting the work using a sequence of different keys corresponding to respective temporally spaced segments of the document, (b) transmitting software code containing an algorithm from a security server to the client, the algorithm having a result that is a function of the state of the client, (c) executing the code at the client and returning the result to the security server, (d) determining whether the result is indicative of an unmodified client. The method further includes (e) transmitting a segment from a server to the client, (f) securely streaming a key corresponding to the transmitted segment from a secure remote server to the client, (g) decrypting the segment using the obtained media key, (h) if step (d) indicates a modified client, preventing further keys from being transmitted, otherwise repeating steps (e) to (g) and repeating steps (b) to (d).

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application is a continuation of U.S. application Ser. No. 11/995,677, filed Aug. 7, 2008, entitled “Multimedia Data Protection”, which is a national phase entry of PCT/GB2006/002619, filed Jul. 14, 2006, designating the United States of America and published in the English language, which claims priority to Application No. GB 0514492.8, filed Jul. 14, 2005. The disclosures of the above-referenced applications are hereby expressly incorporated by reference in their entireties.
  • BACKGROUND
  • 1. Field
  • The present invention relates to the secure distribution of multi-media works that have a temporal dimension such as movies, TV shows, audio documents, etc. In particular, it relates to a system for securely delivering such works to a user in a manner that prevents the user from obtaining an unauthorized copy of the work. Aspects of the invention also have applications in other server-client situations such as on-line banking, gaming, etc.
  • 2. Description of the Related Technology
  • Illicit copying of artistic works is a perennial problem. In the early days of the movie industry, whilst it was possible for unauthorized copies of films to be made, it was expensive to do so and not practicable except for persons with access to specialist equipment. With the advent of home video recorders a new market for movies and other recorded programmes became available to producers whilst simultaneously it became possible for those recordings to be illicitly copied and distributed.
  • Today the DVD format, which provides higher quality playback and a more convenient and compact data carrier, is rapidly supplanting the video. In addition, with the advent of affordable broadband Internet connections, there is now an emerging market for downloading or streaming movies and other media from remote servers onto home computers.
  • Where a media work is downloaded, a copy of it is stored on the hard drive of the computer and it can normally be viewed repeatedly by the user, analogously to watching a video recording. Streaming content, whether live or recorded, is watched as it is transmitted to the computer (as with a conventional TV programme) in almost real-time (there is a short delay due to the need to provide some buffering). It is well known for radio and some TV stations to offer their content in this manner.
  • Whilst these improvements in technology have allowed the development of a promising new market for media companies, there is also a corresponding problem in preventing the production and distribution of unauthorized copies of the works. It now is commonplace for even low-cost home computers to have the capability to record content onto DVDs.
  • Techniques have therefore been developed with the aim of preventing such copying. In a conventional approach, the media supplier, who is referred to here as a “content provider”, owns encoded media works, for example movies, which will be referred to generically as “media works”. These are to be distributed and presented to a user's client program/viewer in a way that does not allow the user to create a copy of the encoded media work. The delivery can be carried out by either streaming over a network or by delivering a physical medium, for example a DVD, to the client.
  • Where the work is transported over a network it is usually secured by cryptographic means to protect the work from being intercepted and copied by a third party. We refer to these cryptographic means as “transport encryption”. (Encryption, which is a security measure, is to be distinguished from encoding, whereby the work is converted and usually compressed into a form that can readily and efficiently be transmitted.) Encryption techniques are sufficiently well developed and secure that the communication over computer networks can be secured in an appropriate way.
  • Before the media work is delivered to the client, the content owner protects the encoded media document using cryptographic means. Within a secure “provider environment”, an encryption tool is used to encrypt the work with a “media key” to create an encrypted encoded media work, the “encrypted work”.
  • The intention is that the client can then only use the work if he has the media key that allows him to decrypt it. This can be embedded in the client program/viewer/player and/or the media, for example in DVD-players and DVDs. (The client program/viewer/player may be a free-standing device or a viewer software program on a computer.)
  • Another option, which is illustrated schematically in FIG. 1, is for the media key to be retrieved from a license server 1 on demand. This allows for streaming of the media work. To support this model, the encryption tool 2 wraps the media key, together with additional information, in a license 3 and sends this to the license server 1. The client then receives an encrypted, encoded media stream 4 from the streaming server 5 that has to be decrypted in a viewer 6 before it can be presented to the client. In order to watch the encrypted movie 7, the viewer requests a license containing the media key from the license server (see “Start-up Phase” in FIG. 1).
  • Once the viewer has received the license 3 (and therefore the media key), it connects to the streaming server 5 from which it receives an encrypted encoded media stream 4. The viewer uses the media key to decrypt the encrypted encoded media stream and present it to the client (see “Streaming phase” in FIG. 1).
  • A major problem in the scenario described above is that the viewer is executed on a host that is controlled by the client. Thus, the viewer is not executed in the trusted environment 8 (where the movie 9 was originally encrypted). There is, therefore, a risk that the client could modify the viewer. Even though the viewer will usually only decrypt and decode part of the media stream, during the whole presentation process every part of the encoded media stream will at some point be present in the viewer memory-image. Another risk is that, since the memory image of the viewer has to contain the key, the user could extract the media key, in which case he would be able to create a copy of the unencrypted encoded media.
  • The problem of modification exists for purely software-based viewers as well as for hardware-based viewers, for example, designated DVD players. Though it is more difficult to modify a hardware-based viewer than to modify a software-based viewer, it is not impossible. Thus there exists a need for a system that addresses these drawbacks.
  • SUMMARY
  • General requirements for any effective protection mechanisms include the following: It should be resource-intensive to break so that the cost of breaking is at least of the same magnitude as the value of the work. Any successful attack should not be generalizable so that it can be applied elsewhere. It should preferably also facilitate detection. The various aspects of the invention described below address these requirements individually and the preferred forms of the invention provide a system that satisfies them all.
  • In the following discussion, a media work is a work that has a temporal aspect, i.e., it contains a number of presentational steps that have to be performed in an appropriate order. The steps are normally computationally independent of each other and can be processed independently. In most cases, the complete presentation takes a significant amount of time: many minutes or some hours in the case of a movie.
  • According to one aspect of the invention there is provided a method of transmitting a media work to a client comprising the steps of:
      • (a) encrypting the work using a sequence of different keys corresponding to respective temporally spaced segments of the work,
      • (b) securely transmitting a first key from a secure server to the client and transmitting the corresponding segment from a server to the client,
      • (c) in the client, using the first key to decrypt the corresponding segment,
      • (d) in the viewer, presenting the decrypted portion,
      • (e) repeating steps (b) to (d) in respect of further segments and keys.
  • The invention may be applied to any kind of media work (as defined above) that has a temporal aspect, and is particularly useful for distributing movies, for example streaming them over the Internet.
  • By dividing the document into a sequence of segments, it becomes impracticable to copy more than a small part because each key can decrypt only one segment, i.e., the keys are functionally independent. Thus, only one segment of the movie at a time can be copied. Furthermore, there should not be a master key that can unlock other keys, i.e., the keys should preferably be structurally independent. Preferably, thousands of different keys are used for a typical length of film such that each corresponds to a segment of a pre-determined length, e.g., of only a few seconds, say less than two or three seconds, and most preferably a second or less. Most kinds of media works only have significant value if they are substantially complete. For example, a movie with only the last few minutes missing will usually be of little value. Thus, someone seeking to illicitly copy a movie will have to decrypt each of the segments.
  • In order to maintain a continuous flow of data decryption, in some embodiments the client may ask for the current key and the next key(s) and cache a small number of keys (e.g., 2, 3, 4 or so) in memory.
  • Normally, the secure server is remote from the viewer, and is referred to herein as a ‘security server’.
  • The movie is generally encrypted in a trusted environment. Preferably, the keys generated during encryption are supplied to the security server, which is within the trusted provider environment. However, although the keys are then transmitted from the security server to the viewer, the movie or other work may be transmitted from elsewhere. For example, it may be streamed from a separate server that is outside the trusted environment. Therefore, in one preferred embodiment, once the movie has been encrypted in the trusted provider environment, it is then supplied to a non-secure streaming server.
  • Thus, in this arrangement, the client, which may be a software viewer program running on a remote computer (e.g., a user's PC) communicates with a security server to receive the keys (referred to as media keys) and with a separate streaming server.
  • The media keys are preferably transmitted to the client following a request from the client, and this is preferably done using a key exchange protocol that makes use of a random data generator and the public key of the security server, which is known to the viewer.
  • In one implementation, when it is necessary to obtain the next media key, the client generates random data and encrypts it with the public key of the security server. The encrypted data may then be included in a request for the next media key, preferably with data identifying the client, which is sent to the security server. When it receives the request, the security server checks whether that client is entitled to receive the media work, decrypts and extracts the random data and performs a function using it and the requested key, to encrypt the key using the random data. In one embodiment, they may be XOR'ed. The result is then sent back to the client. When the client receives the result, it can then extract the requested key from the result by carrying out a corresponding function, for example by XORing it with the same random data that was provided in the original request for the key. In this way the encrypted, encoded media stream can be decrypted without any secret keys hidden in the source code of the viewer.
  • Preferably, the public key is included in the checksum calculation in order to prevent a “man in the middle” attack in which the public key is exchanged.
  • In a preferred form of the protocol, steps are also taken to ensure that the client checked by the mobile guard is the same one as the one generating the random data. This may be done by extending the input to the checksum to include the random data used to request the media key. Thus, the input to the checksum may include code from the client, the public key of the security server and the random data sent with the key request.
  • As external entropy sources can be monitored, the entropy source used for generating the random numbers may be that generated by the executing environment itself in the form of how tasks are scheduled and interrupted. Thus, the random generation process may consist of creating several threads that work on different computational tasks that can be input into a secure hash algorithm along with data from the current state of the viewer and the executing mobile guard.
  • The need for a continuing sequence of keys to be received by the client can be used to enforce user co-operation. Thus, if a certain step required by the provider is not carried out by the client, the supply of keys can be ceased. As will be discussed further below, this step may be an integrity check of the client, and preferably, the request for a new key is only responded to when a so-called “mobile guard” indicates that the viewer is unmodified.
  • Where the mobile guard is employed, it is possible for it to generate the random number used in the preferred key exchange protocol described above, rather than the actual client viewer/player program.
  • It will be appreciated that this enforcement of co-operation is possible because the content provider controls the media work and because of the work's temporal nature, the work can be supplied in small parts with the user being required to co-operate in order to receive subsequent parts. This is in contrast to conventional systems where a license unlocks the whole document, effectively neutralising the temporal property.
  • In an alternative embodiment of the invention the trusted environment is extended so that the streaming server is included within it. When this is done it is possible to have the streaming server generate media keys and encrypt the media stream on the fly. This ensures that each media stream is encrypted with a unique set of media keys. That means that a leaked media key cannot be used to decrypt a different copy of the same movie. To facilitate distribution of the media keys the streaming server sends them to the security server, which will distribute them to the viewer as described above. The downside is that another entity needs to be trusted and that the encryption on the fly is computationally expensive. Thus, there is a trade off here between very high security on the one side and complexity of the trusted environment and computational costs on the other side.
  • The invention is not limited to arrangements where the document is streamed from a remote server. Because it is encrypted, the document can be distributed in any convenient manner. Thus, the encrypted document may be provided to the client from a local server or on a physical medium (e.g., a DVD). The document may then be transmitted from the local server or physical medium to the viewer and decrypted in the same manner as previously discussed.
  • Although this arrangement provides a significant improvement over the prior art system, there still remains the risk that the viewer could be tampered with so that the decrypted work (movie etc.) could be recorded and copied. Thus, preferably, the invention further comprises means for checking the integrity of the viewer to ensure that it has not been tampered with. This may be done by programming it to send a signal such as a checksum to the security server at regular intervals, and/or when a key is requested. Such a signal would be designed to depend on the state of the viewer so that any modification to the viewer would change the signal.
  • However, there is a risk that such a measure could be overcome by programming the modified viewer to send the “correct” signal regardless of its true state. Preferably, therefore, the method further requires that the security server interrogate the viewer using a number of different tests, which vary with time. In a particularly preferred form, the tests comprise the use of randomly generated algorithms which will only return the correct result if the viewer is unmodified. Furthermore, failure to respond or an undue delay in responding can be taken as an indication of viewer modification.
  • Thus, preferably the security server is arranged to cease the supply of keys in the event that viewer modification is detected and/or if such a viewer integrity check is not successful.
  • The most preferred arrangement is for the algorithms to be transmitted by the security server to the client in the form of software code (e.g., machine code). The software code may be termed a “mobile guard”, and is described further herein.
  • Such a system of integrity checking is considered to be an inventive concept in its own right and therefore, viewed from a further aspect, there is provided a method of transmitting data to a client comprising the steps of:
      • (a) transmitting the data to the client,
      • (b) transmitting software code containing an algorithm from a security server to the client, the algorithm having a result that is a function of the state of the client,
      • (c) executing the code at the client,
      • (d) returning the result to the security server, and
      • (e) determining whether the result is indicative of an unmodified viewer.
  • The data may be a media work that is streamed to the client, for example over the Internet, or it can be supplied from a local server, DVD or other media as discussed above. However, as will be discussed more fully below, it may be any kind of data that can be transmitted between server and client. The client may be a program running on a computer or a hardware device such as a TV set-top box. The algorithm referred to in step (b) may be transmitted before any part of the document has been transmitted, or the whole or part of the work may be transmitted before the algorithm. Preferably, the document is not viewed until after step (d) has been carried out.
  • Depending on the outcome in step (d), appropriate action can be taken. Where the work is being streamed, if the viewer is found to be unmodified, the transmission of the work and of any keys required to decrypt it would normally be allowed to continue. However, there may be a further step of (e) ceasing the transmission of the work and/or of keys necessary to decrypt it in the event that the result is not indicative of an unmodified client. Preferably, if no result is returned from the mobile guard, this is also deemed to indicate that the client has been modified.
  • Where the work is being transmitted from a local source such as a local server, DVD, etc. the action may be to cease the transmission of the keys needed to decrypt the document.
  • Alternatively, other action may be taken if it is found that the client has been modified. For example, the transmission could be allowed to continue and evidence gathered to identify the user. This may be appropriate if it is desired to take legal or investigative action, e.g., to detect criminal activity or to prevent future illicit copying of documents.
  • As noted above, the action taken in response to the identification of a modified client may be to cease transmission of decryption keys. It will therefore be appreciated that the method may further comprise dividing the work into a plurality of temporally spaced segments, which are encrypted using different keys. These keys may be distributed to the client sequentially, and preferably as discussed above. Thus, if their distribution is ceased, the remaining part of the work cannot be decrypted.
  • The method is preferably carried out using randomly generated secret algorithms in the software code (as mentioned above). These so-called enforcement algorithms generate a result that is dependent on the state of the client (e.g., of a viewer program), but the correct result is not guessable by the user because of the random aspect. Preferably, they contain a checksum calculation into which the viewer program's code is input. Although the algorithm as a whole is secret, the checksum calculation may be a known one such as the Message Digest Algorithm 5 (MD5) (RFC1321 www.faqs.org/rfcs/rfc1321.html), which may be used in combination with randomized input modification.
  • Input modification refers to the random creation of a modifier that permutates the data that will be input into the checksum. In one implementation, when the software code (referred to here as a “mobile guard”) is generated, a random sequence is determined. When the algorithm is executed, the input code from the viewer is divided into n blocks of the same size. These are then shuffled into the above-mentioned random sequence and the result is then input into the checksum algorithm. Although in this arrangement the checksum algorithm itself is public, its result is a function of the order in which the n blocks are input to it. This order is known to the security server and so the security server can determine whether the result returned to it indicates an intact viewer.
  • An alternative approach to creating an input-filtered checksum is to decompose a known checksum algorithm and reassemble it in a way that reads the input in a given sequence.
  • Instead of using input filtering, it is possible to generate a checksum function from scratch. Thus the input can be split into/words (32 bits) and a function f is created that reads/words from the input and m words from a variable area that outputs a word. The function may comprise a random number of assignments that are performed one after another and the checksum may be the sum modulo 232 of all the results of the application off.
  • Composing functions has the advantage that almost all code of the checksum algorithm is randomly created, leading to more structural diversity in the code. Since the building blocks are quite small, it allows for easier interleaving with other algorithms.
  • The software code also preferably contains additional algorithms, which may be secret or non-secret. They are preferably functionally and/or spatially entangled with the secret algorithm. In this way the client's computer/viewer can be forced to carry out the additional algorithms because if it does not the secret one will not be implemented. The additional algorithms may be used, for example, to check the integrity of viewer hardware.
  • As the mobile guard is present in the same environment as the viewer, it is potentially vulnerable to attacks. A user might try to modify it in order to circumvent the protection methods it implements. Automated attacks on it can be prevented by ensuring that the mobile guards are partly randomly created, as discussed above. In addition, obfuscation transformations may be applied to the mobile guards. The mobile guard may hide the checksum in an opaque data structure that is interleaved with the checksum in a way that is specific to the mobile guard. Variables may be located randomly in the mobile guard's memory and, in addition, the mobile guard's instructions may be split into blocks, which are also located randomly in memory. This preferably includes the entry point into the mobile guard. Indeed, the entry point for one mobile guard can be provided by the previous one.
  • If these steps are carried out, a human attack then becomes necessary to overcome the obfuscation before any automated attack can commence. Such an approach inevitably takes a significant amount of time and so provided the “trust interval” between successive mobile guards is sufficiently short, it will not be effective. In other words, because the mobile guards are replaced frequently, there is insufficient time for this to be worthwhile. Thus, the obfuscation process protects the mobile guard from tampering in the time interval before it is replaced by another mobile guard.
  • There is a risk of an observer spying on memory locations in a computer where the decrypted movie data is stored. If a known memory location is used then the data could be copied. Therefore, it is undesirable for it to be practicable to locate code by identifying a certain memory location (location-based identification) and preferably, once locations have been used, they should not be re-used. Also, pattern-based identification—where code may be sought by looking for sequences like MPEG headers—should preferably be prevented too.
  • The viewer is, therefore, preferably protected by the mobile guard against its state being determined by spying. To do this the mobile guard will preferably further comprise one or more protection algorithms to protect against such attacks. This it may perform obfuscation tasks on the client (e.g., on a viewer program), referred to hereinbelow as “runtime viewer obfuscation”, i.e., obfuscation is carried out on the viewer as it runs. This changes the memory image of the running viewer.
  • This runtime viewer obfuscation is considered a further inventive concept, and thus from another aspect, the invention provides a method of obfuscating an executing viewer, comprising randomising the memory image of the executing viewer.
  • Runtime obfuscation may comprise one or more of the following techniques.
  • Code relocation comprises moving code blocks around in memory. As the program executes, the mobile guard will move the code to other parts of memory, which will then later be executed. This algorithm is preferably tightly interleaved with the checksum calculation.
  • Preferably, code relocation is implemented by (1) identifying all the basic building blocks in the program and partitioning it into small relocatable segments; (2) during execution of the mobile guard these segments may be rearranged in memory to random locations; and (3) modifying all jump instructions to correspond to the new code locations. As a result, an attacker will be confronted by a memory image that changes during the execution of the mobile guard. Since the location of the segments is determined by the mobile guard provided by the security server, it is unpredictable to the attacker who cannot then rely on the assumption that certain memory locations contain certain data.
  • Data relocation comprises moving the data and changing the instructions that access it. Again, the new locations can be determined randomly.
  • Data hiding addresses the problem of location and pattern-based identification. One approach is to apply a two-way function to alter the appearance of the data—effectively to mask it. Preferably, a simple one-time pad approach is used. It may comprise a newly created modulo function that creates an index into an array of random data. The random data may be used to alter the sensitive data by applying the XOR operator between the random and sensitive parts. Preferably it is applied between these and part of the address of the sensitive data.
  • One approach is to scramble (mask) and unscramble the data so that sensitive data is stored in scrambled form, unscrambled when needed, and then re-scrambled or deleted. However, this does leave a short window when the data is unscrambled.
  • However, it is possible to take advantage of stream processing to delay the unscrambling until the data is in the processor's registry.
  • Thus, the actual content decoder may be modified to perform the last decryption operation, as it needs new data. This means that there will not be any decrypted data present in main memory at all. It may be provided using the following steps:
      • a) The Mobile guard modifies the decoder to perform the last decryption step as needed;
      • b) The next encrypted segment is obtained;
      • c) Media key for the encrypted segment is obtained;
      • d) The decryption stream is generated and placed in random places in memory according to how the decoder was modified;
      • e) The decoder will then read a byte or a word at a time and decrypt them as needed.
  • Code diversification comprises operations performed by the mobile guard on the client program during execution. The operations performed change the code such that it consists of different instructions without changing its semantics. This is to prevent pattern-based identification. One or more of the following steps may be carried out:
  • Context-independent instructions may be inserted. These are instructions whose input context may be shared with contexts in the program but whose output context is different from any input context in the program. Since they cannot alter any input context of the program, it does not matter what they process.
  • Context dependent instructions may be replaced by instructions that perform the same function. It will be appreciated that this is more difficult to achieve, but it is also more effective because they cannot be identified by data-flow analysis.
  • Functional independent changes that can be made include changing the order of execution of instructions, inserting instructions with or without temporary variables, re-ordering instructions in memory and making control flow changes.
  • Functional dependent changes require care in order to keep the function and side effects intact. They include replacing instructions with functional equivalents, introducing identity functions, introducing operators so that literal values are replaced by instructions that initialise the value arbitrarily and perform an operation that corrects the value to match the original literal. Also, variables can be introduced so that copies to a destination are replaced by copies of a newly created variable.
  • In an embodiment in which a hardware-based viewer solution is employed, for example a TV set-top box, the distributor of the viewer controls not only the viewer software, but also the viewer environment, i.e., the hardware and operating system. Therefore, a hardware based viewer can generally be checked by a mobile guard in a much more complete manner than a purely software based solution. In this embodiment, the checksum algorithm in the mobile guard is not restricted to checking the viewer software but can also check different aspects of the operating system and the hardware.
  • Thus, the system can be used in two ways in connection with hardware-based viewers. Firstly, it can be used to replace solutions that are based on expensive tamper-proof hardware. Secondly, it can provide additional security measures that come into play in the event that the tamper-proof hardware should be compromised.
  • It will be seen that the invention preferably relates to the combination of individually encrypted segments of the document and the use of the “mobile guard” concept. Thus, viewed from a still further aspect, the invention provides a method of transmitting a media work to a client comprising the steps of:
      • (a) encrypting the work using a sequence of different keys corresponding to respective temporally spaced segments of the work,
      • (b) transmitting software code containing an algorithm from a security server to the client, the algorithm having a result that is a function of the state of the client,
      • (c) executing the code at the client and returning the result to the security server,
      • (d) determining whether the result is indicative of an unmodified viewer,
      • (e) transmitting a segment from a server to the viewer,
      • (f) in the event that the result is indicative of an unmodified viewer, securely streaming a key corresponding to the transmitted segment from a secure remote server to the viewer,
      • (g) decrypting the segment using the key.
  • It will be appreciated that although the steps may be executed in the order in which they are given above, at least some of the steps may be executed in a different order, or concurrently. For example, step (e) may be carried out concurrently with steps (b), (c), (d) or (f), such that the segments are transported before, with or after the keys. However the keys must be available before the segment is decrypted.
  • In one embodiment, the method comprises a further step (h) wherein steps (b) to (g) are repeated.
  • However, generally, the transmitted software code has a certain ‘lifetime’ or ‘trust interval’, for example less than 30 seconds. On the other hand, segments are generally transmitted more frequently than the lifetime of the software code, for example one per second. As such, new software code does not need to be transmitted each time a segment is transmitted, but will generally only need to be transmitted once the lifetime of the present software code has expired. Thus, steps (e) to (g) will generally be repeated until new software code is required, when step (b) will be repeated. In this way one piece of software code (mobile guard) protects the delivery of many keys.
  • Although the execution of the code and determination of whether the result is indicative of an unmodified viewer (steps c and d) can be done more than once for each piece of software code, generally, it will only be necessary to do it once during the lifetime of the software code. As such, steps (c) and (d) will generally only be repeated after step (b) has been repeated.
  • Viewed from a still further aspect, the invention provides a method of transmitting a media work to a client comprising the steps of:
      • (a) encrypting the work using a sequence of different keys corresponding to respective temporally spaced segments of the work,
      • (b) transmitting software code containing an algorithm from a security server to the client, the algorithm having a result that is a function of the state of the client,
      • (c) executing the code at the client and returning the result to the security server,
      • (d) determining whether the result is indicative of an unmodified viewer, and further comprising the steps of:
      • (e) transmitting a segment from a server to the viewer,
      • (f) securely streaming a key corresponding to the transmitted segment from a secure remote server to the viewer,
      • (g) decrypting the segment using the obtained media key,
      • (h) if step (d) indicates a modified viewer, preventing further keys from being transmitted, otherwise repeating steps (e) to (g).
  • Preferably, the method further comprises the step (i) of repeating steps (b) to (d).
  • It will be appreciated that although the steps may be executed in the order in which they are given above, at least some of the steps may be executed in a different order, or concurrently. In fact, some steps may be carried out more times than others.
  • Steps (b) to (d) can be carried out independently of steps (e) to (h), and are preferably carried out concurrently therewith. As mentioned previously, the software code generally has a lifetime that will encompass the sending of many segments and keys. As such, the repetition of steps (b) to (d) (mentioned in step (i)) will generally be carried out less frequently than the repetition of steps (e) to (g) (mentioned in step (h)). Preferably, step (i) is only carried out if the lifetime of the software code has expired.
  • The invention also extends to apparatus configured to operate as discussed above, including a client configured to receive such streamed media and also the server arrangement, both in combination and separately. Thus, from a still further aspect it may provide a system for delivering a media work to a client comprising:
      • (a) means for transmitting the work to the client,
      • (b) means for transmitting software code containing an algorithm from a security server to the client, the algorithm having a result that is a function of the state of the client, and
      • (c) means associated with the security server for receiving the result and determining whether the result is indicative of an unmodified client.
  • Another aspect provides a client, e.g., a viewer for playing a work such as a movie, the client being arranged to: receive the work and to receive software code containing an algorithm from a remote source; to execute the algorithm on the client; and to return a result of the algorithm to the remote source, thereby demonstrating the integrity of the client to the remote source and enabling the playing of the document.
  • The client preferably enables the playing of the work by decrypting it, or decrypting a segment of it using a key supplied to it by the remote source. Preferably the client is configured to request a sequence of keys and uses the keys in sequence to decrypt consecutive sections of the work, which are then played as a continuous presentation. Preferably, as discussed above, the provision of keys is dependent on the client demonstrating its integrity to the source.
  • The invention also extends to a combination of a system for delivering works as described above, in combination with a client, whereby documents are delivered to the client and can only be played if the viewer demonstrates its integrity to the source.
  • It will be seen that, in contrast to prior art software solutions, the present invention does not rely on secrets that are contained in the data that is made available to the user, whether in the program code or in the media documents. It allows the early detection of copy attempts and allows the content provider to initiate counter-measures before a substantial part of the media document can be copied.
  • It has also been recognized that the concept of checking system integrity using a mobile guard has other applications beyond the transmission of documents (as defined) to a client. It can be used generally to verify the integrity and authenticity of code that is run in uncontrolled environments that perform calculations on input data. It can be used to prevent a party from changing the way that data is processed without this being detected. Thus, the discussion above in relation to a media viewer can be applied to any client program. Applications include games, banking, audio, etc.
  • Thus, viewed from a still further aspect, the invention comprises transmitting software code (such as a mobile guard) from a secure source to a client computer running a client program, the software code comprising an algorithm having a result that is dependent on the state of the client program, executing the software code and returning the result to the source, whereby the source can determine the integrity of the client program. The invention also extends to apparatus arranged to operate in accordance with such a method.
  • This aspect of the invention may employ any or all of the preferred features discussed above, in particular concerning the mobile guard. References above to media works apply likewise to temporal payload data sent between server and client. Thus, the service provider can enforce the cooperation of the user's client in the same manner and can withhold further payload data if either cooperation ceases or tampering is detected.
  • Thus, it will be appreciated that any client that is in communication with a server can have its integrity checked on an on-going basis. The invention therefore allows a client that operates in an uncontrolled environment to be trusted. If it transpires that the integrity of a client has been compromised then action can be taken. For example, communication with the client could be terminated, the provision of decryption keys suspended (as with the media streaming applications discussed above) and/or steps taken to gather evidence (e.g., in the case of suspected fraudulent attacks on banking systems).
  • The invention is useful in the context of distributed calculations where, although confidentiality and dishonesty are not usually issues, the correct execution of software is. Thus, the mobile guard may be used to protect against intentional or unintentional modification of the client—both its software and, if required, hardware. Thus, the instance that launches the distributed computing job can use mobile guards to check the correct operation of the clients at remote nodes that carry out calculations.
  • In the context of on-line gaming, modification of client programs can enable cheating which, if uncontrolled could cause customer dissatisfaction and lead to loss of revenue. The data concerned is not confidential and there is little point in recording it (as with a media work), so it is normally sufficient to verify only the integrity of the client software. Where the game operated on a client-server basis, mobile guards can be applied as discussed previously. If the user does not allow cooperation with the mobile guard then he can be refused updates on the global game-state.
  • In the case of home banking, mobile guards can be used to make sure that third parties do not access confidential data. While a normal user will not normally be interested in modifying his client program, he may be the victim of a man-in-the-middle attack. The banking server could therefore use a mobile guard to verify the integrity and authenticity of the home banking client and it may also contain the public key of the banking server. This public key is used to encrypt all data that is passed from the home banking client to the banking server and since the integrity of the mobile guard is guaranteed, the user can be sure that his data is kept confidential.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • Certain embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings:
  • FIG. 1 is a schematic drawing of a prior art media streaming system as described above;
  • FIG. 2 is a schematic overview of a first embodiment of the invention;
  • FIG. 3 is a schematic diagram showing the components of a randomly generated checksum algorithm as used in the embodiment;
  • FIG. 4 is a flow chart showing the operation of the embodiment; and
  • FIG. 5 is a flow chart of the server algorithm employed in the embodiment.
  • DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS
  • As may be seen from FIG. 2, a client is provided with a viewer 10 which can be used to view media (e.g., a movie) that is streamed from a streaming server 11 or alternatively from a local storage media, e.g., CD 12. Each of these components of the system is outside the trusted environment 13. Within the trusted environment is the unencrypted movie 14, a protection tool 15 to generate a protected movie 16 and a security server 17.
  • As in the prior art system illustrated in FIG. 1, the content owner protects the encoded media document, before it is delivered to the client. However, instead of using a single media key, protection tool 15 encrypts the movie with a very large number (thousands) of media keys 20. This process yields an encrypted, encoded media, the protected movie 16.
  • The media keys 20 are distributed so that they are spread out in time; during presentation of a media resource, they are securely streamed to the client one at a time at intervals on request as will be described below. The media itself is streamed separately. Each key comprises only a few bytes (about sixteen) so the resources needed to stream the keys create a very low overhead.
  • Each key can be used to decrypt only about a second, or at most a few seconds, of the movie so that obtaining only a single key is of little value.
  • In the first embodiment of the invention, the protected movie is delivered to the client in form of a data stream via path A, streaming server 11 and media stream 18. In further embodiments, tangible media, e.g., a CD or DVD 12 are used.
  • The viewer 10 is executed on the client's host and is arranged to receive the protected movie 16 from the streaming server 11 via media stream 18 (or from the CD/DVD in other embodiments).During the presentation process, the viewer 10 communicates with a security server 17 to download the necessary media keys 20 to decrypt the protected movie 16.
  • In addition, the viewer 10 also downloads pieces of code called mobile guards 19 at regular intervals of about 30 seconds. These each have embedded within them secret information in the form of an algorithm that is created in the security server 17. The execution of these algorithms is necessary to make use of the streamed data 18. When each mobile guard 19 is transferred into the viewer it performs calculations determined by the secret algorithm and returns the result to the security server. The mobile guard is structured in such a way that the result of the calculation is only correct if the viewer has not been tampered with. The result of the secret algorithm contains a checksum that proves the integrity of the viewer to the security server.
  • The mobile guard can also have other additional algorithms functionally and spatially entangled with the secret algorithm. In this way the client's computer/viewer can be forced to carry out the additional algorithms because if it does not the secret one will not be implemented. In this way, the viewer may be fully checked.
  • If the result returned to the security server 17 by the mobile guard does not match the expected result, the security server stops the distribution of the media keys 20 to the viewer. The same happens if the viewer 10 refuses a mobile guard or if the correct result does not arrive within a certain time. The key exchange protocol will be explained in more detail later.
  • The secret algorithms are based on checksum calculations that have a high probability of detecting changes in the checked data (i.e., the viewer code). As may be seen from FIG. 3, a randomly generated checksum algorithm 21 (for use in a mobile guard) uses a checksum calculation divided into two steps: input modification 22, which is randomized, and a known checksum calculation 23 which is performed on the modified input. These steps together make the randomized and secret checksum algorithm.
  • Input modification refers to the random creation of a modifier that permutates the data that will be input into checksum calculation 23. When a mobile guard is generated by the security server, a random sequence is determined. When the checksum algorithm 21 is executed by the viewer, the input Program Code from the viewer is divided into n blocks of the same size. These are then shuffled into the above-mentioned random sequence in the Input Modification stage 22. The result of this is then input into the Checksum Calculation stage 23. This uses the known Message Digest Algorithm (MD5). The checksum calculation is then carried out and its result returned to the security server.
  • It will be appreciated that although the checksum algorithm itself is public, its result is a function of the order in which the n blocks are input to it. This order is known to the security server and so the security server can determine whether the result returned to it indicates an intact viewer.
  • The mobile guard needs to be protected against tampering and against the spying out of its inner workings. The first aspect of the protection of the mobile guard is to randomly create new versions each time a viewer needs to be checked. Secondly the lifetime of the mobile guard in the viewer environment when it is being used is short (less than thirty seconds). Although human (i.e., intelligent, as opposed to automated) attacks on the mobile guard are theoretically possible, they would take a significant amount of time. By having an expiration time of some seconds for each mobile guard, human-assisted attacks therefore become virtually impossible because the mobile guard is redundant long before any attack can be completed.
  • The mobile guard is obfuscated, as previously discussed, to defend against an automated attack.
  • The mobile guard randomises the memory image of the running viewer, referred to herein as ‘runtime viewer obfuscation’. Code and data areas of the viewer are swapped and the stack is scrambled. This is discussed more fully below.
  • The effect of runtime viewer obfuscation is to make sure that only intellectual attacks can be performed on the runtime image of the viewer because it randomises and thereby hides the memory locations of the decrypted, encoded stream.
  • In order to randomize the location of memory accesses, the mobile guard modifies the structure of the viewer code and the data area. The code and data area are split into logical segments. Care is taken that segment borders are not located inside opcodes.
  • After a newly downloaded mobile guard receives control and before starting with the decryption of the stream, the mobile guard relocates the segments to new positions. This process includes the modification of code segments—similar to relocation performed by dynamic linkers—to make sure that:
      • 1. Jump- and Branch-instructions are transferring control to the relocated positions.
      • 2. Read- and Write-instruction are accessing the data at the relocated positions.
  • After relocating the segments, the mobile guard performs its operation until it is replaced by the next mobile guard.
  • The mobile guard needs to know the entry points of certain functions in the viewer. The new positions of the segments are known by the security server and provided to the mobile guard. In this way there is no need to transfer information between two mobile guards on the client side.
  • With regard to stack scrambling, the stack contains the return addresses to prior function calls. This can be used to either spy out control flow or to alter the control flow of the viewer by changing a return address on the stack. In such an attack, when the program is about to jump back to the calling function, it could instead be transferring control to possible hostile code.
  • To protect the stack against such an attack, a method is used that gradually scrambles the stack as new return addresses are added to it. The checked code will, after a function call, transfer control to a scramble function in the mobile guard, which scrambles the new return address on the stack before returning control back to the calling function. To unscramble the stack a corresponding unscramble function in the mobile guard is called before using any return address.
  • The implementation of the scramble function takes advantage of the fact that mobile guards are created as needed in order to check the viewer. This enables a unique scramble and unscramble function to be created in each mobile guard. The scramble function basically consists of a set of random data created by the security server and contained in the mobile guard that is XORed with the return addresses on the stack of the viewer. To select which part of the random data to use, a simple mathematical function is applied to compute an index into the set of random data.
  • The viewer is therefore protected by the mobile guard against its state (including the position of the control flow and variable content) being determined by spying (as discussed previously).
  • The media keys are transmitted at a rate of approximately one per second to the viewer. This is done using a key exchange protocol that makes use of a random data generator and the public key of the security server, which is known to the viewer. When it is necessary to obtain the next media key the viewer 10 generates sixteen bytes of random data and encrypts them with the public key of the security server 17. The encrypted data is then included in a request for the key, which is sent to the security server.
  • The security server examines the request and only approves it if the mobile guard indicates that everything is correct in the viewer. If the mobile guard indicates that everything is fine, the security server extracts the random data, XOR's it with the requested key and sends the result back to the viewer.
  • When the viewer receives the result, it extracts the requested key from the result by XORing it with the same random data that was provided in the original request for the key.
  • This protocol provides a way to decrypt the encrypted, encoded media stream, without any secret keys hidden in the source code of the viewer. The lifetime of a key is a only few seconds, which prevents the secure streaming process from constituting a single point of failure in the event of the extraction of one or a few secret keys.
  • It will be appreciated that there are effectively two separate threads that are carried out by the client and these are summarised in the flow chart of FIG. 4.
  • The first thread is verification. The client receives a mobile guard, which then verifies the client program. Once verification has been confirmed, a number n of keys can be received during the following trust interval until the mobile guard expires. The thread must then be repeated with a new mobile guard.
  • Running in parallel to this is the presentation thread. For each key, a segment of the media stream is received decrypted and presented.
  • FIG. 5 summarises the operation of the server. On receiving a key request, it sends a key to the client if, and only if, the mobile guard is still alive (i.e., if it is still within the trust interval of that mobile guard). If the mobile guard has expired, a new mobile guard is sent to the client and this is used to verify the client. If the result is incorrect, the client is deemed to have been tampered with and key transmission is then stopped. If the result is satisfactory, then a new trust interval commences and during it the keys are sent to the client.

Claims (29)

1. A method of transmitting a media work to a client comprising:
(a) encrypting the work using a sequence of different keys corresponding to respective temporally spaced segments of the work;
(b) securely transmitting a first key from a secure server to the client and transmitting the corresponding segment from a server to the client;
(c) in the client, using the first key to decrypt the corresponding segment, (d) in the client, presenting the decrypted portion; and
(e) repeating steps (b) to (d) in respect of further segments and keys,
wherein the keys are transmitted using a key exchange protocol that makes use of a random data generator and the public key of the secure server, the public key being known to the client.
2. The method as claimed in claim 1, wherein the client encrypts random data generated by the random data generator with the public key of the secure server to create encrypted data, and requests a key from the secure server, the encrypted data being sent to the secure server with the request for the key.
3. The method as claimed in claim 2, wherein the secure server decrypts and extracts the random data, and uses the random data to encrypt the requested key.
4. The method as claimed in claim 3, wherein the secure server performs a function using the random data in order to encrypt the key.
5. The method as claimed in claim 4, wherein the key and the random data are XOR'd.
6. The method as claimed in claim 2, wherein the encrypted requested key is sent to the client and the client extracts the requested key using the random data previously generated.
7. The method as claimed in claim 2, wherein the client comprises the random data generator.
8. The method as claimed in claim 2, wherein sixteen bytes of random data are used in each key request.
9. The method as claimed in claim 1, wherein the keys are delivered cryptographically independently of each other such that no key can be used to decrypt more than one segment.
10. The method as claimed in claim 1, wherein keys are only supplied following a check that the client is entitled to receive the document.
11. The method as claimed in claim 1, wherein each key corresponds to a segment of a pre-determined length.
12. The method as claimed in claim 1, wherein the secure server is remote from the client.
13. The method as claimed in claim 1, wherein the server and the secure server are different servers.
14. The method as claimed in claim 1, wherein the server and the secure server are the same server.
15. The method as claimed in claim 1, wherein each key must be requested individually by the client.
16. The method as claimed in claim 1, further comprising checking the integrity of the client to ensure that the client has not been tampered with.
17. The method as claimed in claim 16, wherein the secure server is arranged to cease the supply of keys in the event that either client modification is detected or if the client integrity check is not successful.
18. The method as claimed in claim 16, wherein the integrity of the client is checked by software code containing an algorithm which is transmitted from a security server to the client.
19. The method as claimed in claim 18, wherein each key is transmitted only during a trust interval of the transmitted software code that has successfully verified the integrity of the client.
20. The method as claimed in claim 16, wherein checking the integrity of the client comprises the use of randomly generated algorithms which will only return the correct result if the client is unmodified.
21. The method as claimed in claim 1, further comprising transmitting software code containing an algorithm from a security server to the client, the algorithm having a result that is a function of the state of the client, executing the code at the client, and determining whether the result is indicative of an unmodified client.
22. The method as claimed in claim 21, wherein the secure server and the security server are the same server.
23. The method as claimed in claim 21, wherein the result is returned to the security server.
24. The method as claimed in claim 21, wherein keys are only transmitted if the result is indicative of an unmodified client.
25. The method as claimed in claim 21, wherein the code contains a checksum calculation into which program code of the client and/or memory image of the client is input.
26. The method as claimed in claim 1, wherein the media work is streamed to the client from a remote server.
27. An apparatus configured to operate according to the method of claim 1.
28. A system for transmitting a media work to a client, the system comprising:
i) a protection tool arranged to encrypt the work using a sequence of different keys corresponding to respective temporally spaced segments of the work;
ii) a secure server arranged to a) transmit a first key to the client;
iii) a server arranged to b) transmit a first segment corresponding to the first key to the client; and
iv) a client arranged to c) receive the first key and the first segment, decrypt the first segment using the first key, and present the decrypted portion;
wherein the secure server, server and client are arranged to carry out steps a), b) and c) for further segments and keys, and
wherein the secure server is arranged to transmit the keys using a key exchange protocol that makes use of a random data generator and the public key of the secure server, the public key being known to the client.
29. A system for transmitting a media work to a client, the system comprising:
i) a secure server arranged to a) transmit a first key to the client, the first key being one of a sequence of different keys with which temporally spaced segments of the work are encrypted; and
ii) a server arranged to b) transmit a first segment corresponding to the first key to the client;
wherein the secure server and server are arranged to carry out steps a) and b) for further segments and keys, and
wherein the secure server is arranged to transmit the keys using a key exchange protocol that makes use of a random data generator and the public key of the secure server, the public key being known to the client.
US14/109,888 2005-07-14 2013-12-17 Multimedia data protection Abandoned US20140189358A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/109,888 US20140189358A1 (en) 2005-07-14 2013-12-17 Multimedia data protection

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
GB0514492.8 2005-07-14
GBGB0514492.8A GB0514492D0 (en) 2005-07-14 2005-07-14 Secure media streaming
PCT/GB2006/002619 WO2007007112A2 (en) 2005-07-14 2006-07-14 Multimedia data protection
US99567708A 2008-08-07 2008-08-07
US14/109,888 US20140189358A1 (en) 2005-07-14 2013-12-17 Multimedia data protection

Related Parent Applications (2)

Application Number Title Priority Date Filing Date
US11/995,677 Division US8627081B2 (en) 2005-07-14 2006-07-14 Multimedia data protection
PCT/GB2006/002619 Division WO2007007112A2 (en) 2005-07-14 2006-07-14 Multimedia data protection

Publications (1)

Publication Number Publication Date
US20140189358A1 true US20140189358A1 (en) 2014-07-03

Family

ID=34897225

Family Applications (2)

Application Number Title Priority Date Filing Date
US11/995,677 Active 2029-04-29 US8627081B2 (en) 2005-07-14 2006-07-14 Multimedia data protection
US14/109,888 Abandoned US20140189358A1 (en) 2005-07-14 2013-12-17 Multimedia data protection

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/995,677 Active 2029-04-29 US8627081B2 (en) 2005-07-14 2006-07-14 Multimedia data protection

Country Status (10)

Country Link
US (2) US8627081B2 (en)
EP (1) EP1913774B1 (en)
JP (2) JP2009501470A (en)
KR (1) KR20080037025A (en)
CN (1) CN101233755A (en)
AU (1) AU2006268017A1 (en)
CA (1) CA2615469A1 (en)
GB (2) GB0514492D0 (en)
RU (1) RU2449494C2 (en)
WO (1) WO2007007112A2 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130290737A1 (en) * 2007-03-29 2013-10-31 Gary Stephen Shuster Method of distributing a decryption key in fixed-content data
US9152805B2 (en) * 2011-07-15 2015-10-06 Socionext Inc. Security device
US20150371039A1 (en) * 2013-02-12 2015-12-24 F-Secure Corporation Improved Malware Detection
RU2657168C2 (en) * 2016-04-29 2018-06-08 Общество с ограниченной ответственностью "Общество Сферического Кино" Software and hardware complex for automatic calibration of multiprojector systems with possibility to play content in high-permission using encryption facilities and digital distribution, method of content encryption for use in the method of content reproducing
US11398903B1 (en) * 2014-11-13 2022-07-26 Chol, Inc. System and method for generating a cryptographic key
US11757634B2 (en) 2021-03-30 2023-09-12 Bank Of America Corporation System for secure client-side cryptographic key retrieval using cryptographic key splitting and wrapping

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2078406A2 (en) * 2006-10-27 2009-07-15 Secustream Technologies AS Protecting data from access in online game
GB2443264A (en) * 2006-10-27 2008-04-30 Ntnu Technology Transfer As Integrity checking method for a device in a computer network, which controls access to data; e.g. to prevent cheating in online game
DE102006060043A1 (en) * 2006-12-19 2008-06-26 Siemens Ag Method and transmitter for providing a data stream, method and receiver for retrieving at least one data segment of a data stream
KR100914771B1 (en) * 2007-05-09 2009-09-01 주식회사 웰비아닷컴 System and method for security using one-time execution code
EP2193474A4 (en) 2007-08-29 2011-10-05 Cdnetworks Co Ltd Protection against unauthorized copying of digital media content
US8301570B2 (en) * 2007-10-29 2012-10-30 Infosys Technologies Limited Method and system for data security in an IMS network
US8005227B1 (en) * 2007-12-27 2011-08-23 Emc Corporation Key information consistency checking in encrypting data storage system
WO2009139650A1 (en) * 2008-05-12 2009-11-19 Business Intelligence Solutions Safe B.V. A data obfuscation system, method, and computer implementation of data obfuscation for secret databases
KR101666831B1 (en) * 2008-11-26 2016-10-17 캘거리 싸이언티픽 인코포레이티드 Method and system for providing remote access to a state of an application program
US10055105B2 (en) 2009-02-03 2018-08-21 Calgary Scientific Inc. Method and system for enabling interaction with a plurality of applications using a single user interface
US20100223114A1 (en) * 2009-03-02 2010-09-02 Cisco Technology Digital signage proof of play
US8812959B2 (en) * 2009-06-30 2014-08-19 International Business Machines Corporation Method and system for delivering digital content
US8544033B1 (en) 2009-12-19 2013-09-24 Cisco Technology, Inc. System and method for evaluating content in a digital signage environment
CN101924749A (en) * 2010-01-28 2010-12-22 赵路 System for realizing safe network browsing and method thereof
US8838954B2 (en) * 2010-02-02 2014-09-16 Futurewei Technologies, Inc. Media processing devices for adaptive delivery of on-demand media, and methods thereof
CN102882845B (en) * 2010-04-07 2016-07-13 苹果公司 In real time or quasi real time streaming
GB201008888D0 (en) * 2010-05-27 2010-07-14 Qinetiq Ltd Network security
US9135352B2 (en) 2010-06-03 2015-09-15 Cisco Technology, Inc. System and method for providing targeted advertising through traffic analysis in a network environment
US9741084B2 (en) 2011-01-04 2017-08-22 Calgary Scientific Inc. Method and system for providing remote access to data for display on a mobile device
US9258587B2 (en) * 2011-01-05 2016-02-09 Verizon Patent And Licensing Inc. Content blackout determinations for playback of video streams on portable devices
CA2734860A1 (en) 2011-03-21 2012-09-21 Calgary Scientific Inc. Method and system for providing a state model of an application program
SG2014011506A (en) 2011-08-15 2014-05-29 Calgary Scient Inc Non-invasive remote access to an application program
EP2745467A4 (en) 2011-08-15 2015-10-14 Calgary Scient Inc Method for flow control and for reliable communication in a collaborative environment
US9489541B2 (en) * 2011-09-09 2016-11-08 Nvidia Corporation Content protection via online servers and code execution in a secure operating system
US9596320B2 (en) 2011-09-30 2017-03-14 Calgary Scientific Inc. Uncoupled application extensions including interactive digital surface layer for collaborative remote application sharing and annotating
US9787463B2 (en) 2011-10-14 2017-10-10 Maxlinear, Inc. Method and system for server-side message handling in a low-power wide area network
JP6172537B2 (en) 2011-11-23 2017-08-02 カルガリー サイエンティフィック インコーポレイテッド Method and system for federated remote application sharing and conferencing
US8792912B2 (en) 2011-12-22 2014-07-29 Cisco Technology, Inc. System and method for providing proximity-based dynamic content in a network environment
CA2865707A1 (en) 2012-03-02 2013-09-06 Calgary Scientific Inc. Remote control of an application using dynamic-linked library (dll) injection
US9729673B2 (en) 2012-06-21 2017-08-08 Calgary Scientific Inc. Method and system for providing synchronized views of multiple applications for display on a remote computing device
CN103747039B (en) * 2012-12-21 2017-06-13 北京海威汇达计算机技术有限责任公司 Digital film copy distribution system
CN104134021B (en) * 2013-06-20 2016-03-02 腾讯科技(深圳)有限公司 The anti-tamper verification method of software and device
CA2919106C (en) * 2013-07-23 2018-07-17 Ericsson Ab Media client device authentication using hardware root of trust
US9569618B2 (en) * 2013-08-28 2017-02-14 Korea University Research And Business Foundation Server and method for attesting application in smart device using random executable code
CN105765923B (en) 2013-11-29 2019-11-12 卡尔加里科技股份有限公司 The method of the connection of client to non-managed service is provided in client-server remote access system
EP2958039B1 (en) * 2014-06-16 2019-12-18 Vodafone GmbH Device for decrypting and providing content of a provider and method for operating the device
US9613226B2 (en) 2014-10-01 2017-04-04 VYRTY Corporation Secure access to individual information
US10015264B2 (en) 2015-01-30 2018-07-03 Calgary Scientific Inc. Generalized proxy architecture to provide remote access to an application framework
WO2016120730A1 (en) 2015-01-30 2016-08-04 Calgary Scientific Inc. Highly scalable, fault tolerant remote access architecture and method of connecting thereto
EP3278259B1 (en) * 2015-03-30 2020-12-23 Irdeto B.V. Data protection
CN104978542B (en) * 2015-06-11 2019-08-13 福建天晴数码有限公司 The method and system of safe data storage and access data
US10348695B1 (en) 2016-05-26 2019-07-09 VYRTY Corporation Secure access to individual information
US10432685B2 (en) * 2016-05-31 2019-10-01 Brightcove, Inc. Limiting key request rates for streaming media
US11343330B2 (en) 2018-04-18 2022-05-24 VYRTY Corporation Secure access to individual information
CN109409084B (en) * 2018-09-21 2021-06-25 中国科学院信息工程研究所 Chain type data storage structure for detecting falsified return address
US11550903B1 (en) * 2019-04-26 2023-01-10 Joseph Alan Epstein System and method for trustworthiness, reputation, provenance, and measurement of software

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010036271A1 (en) * 1999-09-13 2001-11-01 Javed Shoeb M. System and method for securely distributing digital content for short term use
US20020016919A1 (en) * 1998-08-05 2002-02-07 Hewlett-Packard Company Media content protection utilizing public key cryptography
US20030097655A1 (en) * 2001-11-21 2003-05-22 Novak Robert E. System and method for providing conditional access to digital content
US20030188154A1 (en) * 2000-08-11 2003-10-02 Dallard Nigel Stephen System and method for pre-encryption of transmitted content
US20040083177A1 (en) * 2002-10-29 2004-04-29 General Instrument Corporation Method and apparatus for pre-encrypting VOD material with a changing cryptographic key
US20050033983A1 (en) * 2003-08-06 2005-02-10 Hiroshi Takekawa Secure device, information processing terminal, integrated circuit, terminal application generation apparatus, application authentication method
US7430670B1 (en) * 1999-07-29 2008-09-30 Intertrust Technologies Corp. Software self-defense systems and methods

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5544163A (en) * 1994-03-08 1996-08-06 Excel, Inc. Expandable telecommunications system
JPH09139849A (en) 1995-11-13 1997-05-27 Mita Ind Co Ltd Enciphering method for facsimile equipment
MXPA99004611A (en) * 1996-11-18 2005-01-25 Mci Worldcom Inc A communication system architecture.
IL122106A (en) 1997-11-04 2010-11-30 Enco Tone Ltd Method and algorithms for identification and validation
US6185685B1 (en) * 1997-12-11 2001-02-06 International Business Machines Corporation Security method and system for persistent storage and communications on computer network systems and computer network systems employing the same
US6266754B1 (en) * 1998-05-29 2001-07-24 Texas Instruments Incorporated Secure computing device including operating system stored in non-relocatable page of memory
ES2207285T3 (en) * 1998-09-22 2004-05-16 Infineon Technologies Ag PROCEDURE FOR THE UTENTIFICATION OF AT LEAST ONE SUBSCRIBER DURING AN EXCHANGE OF DATA.
US6535687B1 (en) * 1999-07-23 2003-03-18 Sarnoff Corporation Method and system for deterring electronic video piracy through image rearrangement
US7080257B1 (en) * 2000-03-27 2006-07-18 Microsoft Corporation Protecting digital goods using oblivious checking
US7743259B2 (en) * 2000-08-28 2010-06-22 Contentguard Holdings, Inc. System and method for digital rights management using a standard rendering engine
US7165175B1 (en) * 2000-09-06 2007-01-16 Widevine Technologies, Inc. Apparatus, system and method for selectively encrypting different portions of data sent over a network
US7242772B1 (en) 2000-09-07 2007-07-10 Eastman Kodak Company Encryption apparatus and method for synchronizing multiple encryption keys with a data stream
WO2002023315A2 (en) 2000-09-12 2002-03-21 Aladdin Knowledge Systems, Ltd. System for managing rights and permitting on-line playback of digital content
JP2002092044A (en) 2000-09-19 2002-03-29 Olympus Optical Co Ltd Equipment management system and its method and recording medium with equipment management program recorded thereon
KR20030094216A (en) * 2000-10-26 2003-12-11 제너럴 인스트루먼트 코포레이션 Initial viewing period for scalable authorization of streaming multimedia content
US7150045B2 (en) * 2000-12-14 2006-12-12 Widevine Technologies, Inc. Method and apparatus for protection of electronic media
DE60143452D1 (en) * 2000-12-22 2010-12-23 Irdeto Eindhoven B V SYSTEM WITH CONDITIONAL ACCESS
US7251833B2 (en) * 2000-12-29 2007-07-31 International Business Machines Corporation Digital media delivery with local cache and streaming tokens
JP2002297452A (en) * 2001-03-30 2002-10-11 Matsushita Electric Ind Co Ltd Record regenerating device, controlling method, and unfairness preventing system
US7111789B2 (en) * 2001-08-31 2006-09-26 Arcot Systems, Inc. Enhancements to multi-party authentication and other protocols
US7243226B2 (en) * 2001-12-12 2007-07-10 Valve Corporation Method and system for enabling content security in a distributed system
US7509687B2 (en) * 2002-03-16 2009-03-24 Trustedflow Systems, Inc. Remotely authenticated operation method
US7299292B2 (en) * 2002-03-29 2007-11-20 Widevine Technologies, Inc. Process and streaming server for encrypting a data stream to a virtual smart card client system
US6880149B2 (en) * 2002-04-01 2005-04-12 Pace Anti-Piracy Method for runtime code integrity validation using code block checksums
US7346780B2 (en) * 2002-04-03 2008-03-18 Microsoft Corporation Integrity ordainment and ascertainment of computer-executable instructions
US7124445B2 (en) * 2002-06-21 2006-10-17 Pace Anti-Piracy, Inc. Protecting software from unauthorized use by converting source code modules to byte codes
JP2004133801A (en) 2002-10-11 2004-04-30 Toshiba Corp System and method for providing contents
US20040083373A1 (en) * 2002-10-28 2004-04-29 Perkins Gregory M. Automatically generated cryptographic functions for renewable tamper resistant security systems
US7287052B2 (en) 2002-11-09 2007-10-23 Microsoft Corporation Challenge and response interaction between client and server computing devices
FR2849230B1 (en) * 2002-12-24 2005-04-22 Francois Bangui METHOD AND APPARATUS FOR VERIFYING THE INTEGRITY OF A SOFTWARE APPLICATION WITHOUT AN ENCRYPTION / DECRYMENT KEY
US7366906B2 (en) * 2003-03-19 2008-04-29 Ricoh Company, Ltd. Digital certificate management system, digital certificate management apparatus, digital certificate management method, program and computer readable information recording medium
GB0309161D0 (en) 2003-04-23 2003-05-28 Hewlett Packard Development Co Cryptographic method and apparatus
JP4568489B2 (en) 2003-09-11 2010-10-27 富士通株式会社 Program protection method, program protection program, and program protection apparatus
US8768844B2 (en) * 2004-10-06 2014-07-01 Sony Corporation Method and system for content sharing and authentication between multiple devices
US8887287B2 (en) * 2004-10-27 2014-11-11 Alcatel Lucent Method and apparatus for software integrity protection using timed executable agents

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020016919A1 (en) * 1998-08-05 2002-02-07 Hewlett-Packard Company Media content protection utilizing public key cryptography
US7430670B1 (en) * 1999-07-29 2008-09-30 Intertrust Technologies Corp. Software self-defense systems and methods
US20010036271A1 (en) * 1999-09-13 2001-11-01 Javed Shoeb M. System and method for securely distributing digital content for short term use
US20030188154A1 (en) * 2000-08-11 2003-10-02 Dallard Nigel Stephen System and method for pre-encryption of transmitted content
US20030097655A1 (en) * 2001-11-21 2003-05-22 Novak Robert E. System and method for providing conditional access to digital content
US6865555B2 (en) * 2001-11-21 2005-03-08 Digeo, Inc. System and method for providing conditional access to digital content
US20040083177A1 (en) * 2002-10-29 2004-04-29 General Instrument Corporation Method and apparatus for pre-encrypting VOD material with a changing cryptographic key
US20050033983A1 (en) * 2003-08-06 2005-02-10 Hiroshi Takekawa Secure device, information processing terminal, integrated circuit, terminal application generation apparatus, application authentication method

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130290737A1 (en) * 2007-03-29 2013-10-31 Gary Stephen Shuster Method of distributing a decryption key in fixed-content data
US9081972B2 (en) * 2007-03-29 2015-07-14 Gary Stephen Shuster Method of distributing a decryption key in fixed-content data
US9152805B2 (en) * 2011-07-15 2015-10-06 Socionext Inc. Security device
DE102012209249B4 (en) * 2011-07-15 2020-02-06 Socionext Inc. Security device and host device for exchanging scrambled encryption data
US20150371039A1 (en) * 2013-02-12 2015-12-24 F-Secure Corporation Improved Malware Detection
US9910983B2 (en) * 2013-02-12 2018-03-06 F-Secure Corporation Malware detection
US11398903B1 (en) * 2014-11-13 2022-07-26 Chol, Inc. System and method for generating a cryptographic key
US20230012182A1 (en) * 2014-11-13 2023-01-12 Chol, Inc. System and method for generating a cryptographic key
US11716197B2 (en) * 2014-11-13 2023-08-01 Chol, Inc. System and method for generating a cryptographic key
US20240022399A1 (en) * 2014-11-13 2024-01-18 Chol, Inc. System and method for generating a cryptographic key
RU2657168C2 (en) * 2016-04-29 2018-06-08 Общество с ограниченной ответственностью "Общество Сферического Кино" Software and hardware complex for automatic calibration of multiprojector systems with possibility to play content in high-permission using encryption facilities and digital distribution, method of content encryption for use in the method of content reproducing
US11757634B2 (en) 2021-03-30 2023-09-12 Bank Of America Corporation System for secure client-side cryptographic key retrieval using cryptographic key splitting and wrapping

Also Published As

Publication number Publication date
JP2013059078A (en) 2013-03-28
US8627081B2 (en) 2014-01-07
KR20080037025A (en) 2008-04-29
CN101233755A (en) 2008-07-30
RU2008104050A (en) 2009-08-20
RU2449494C2 (en) 2012-04-27
GB2442691A (en) 2008-04-09
GB0802795D0 (en) 2008-03-26
WO2007007112A2 (en) 2007-01-18
EP1913774B1 (en) 2019-02-27
CA2615469A1 (en) 2007-01-18
GB2442691B (en) 2011-05-25
GB0514492D0 (en) 2005-08-17
JP2009501470A (en) 2009-01-15
US20090132823A1 (en) 2009-05-21
EP1913774A2 (en) 2008-04-23
AU2006268017A1 (en) 2007-01-18
WO2007007112A3 (en) 2007-06-14

Similar Documents

Publication Publication Date Title
US8627081B2 (en) Multimedia data protection
US7920702B2 (en) Digital rights management system and method
JP5192556B2 (en) Reprogrammable security to regulate piracy and enable interactive content
KR100362219B1 (en) Method and system for distributing programs using tamper resistant processor
CA2428953C (en) Secure media path methods, systems, and architecture
US20060149683A1 (en) User terminal for receiving license
US8595492B2 (en) On-demand protection and authorization of playback of media assets
AU2002233609A1 (en) Digital rights management system and method
EP3198498B1 (en) A challenge-response method and associated computing device
KR19990037007A (en) Security processor with external memory using block chaining and block reordering
CN1759560A (en) Protected return path from digital rights management dongle
CN113411638A (en) Video file playing processing method and device, electronic equipment and storage medium
US20190188157A1 (en) Method and apparatus to dynamically encode data at runtime
Grimen et al. Software-based copy protection for temporal media during dissemination and playback
CN115225934A (en) Video playing method, system, electronic equipment and storage medium
Peinado Digital Rights Management and Windows Media Player

Legal Events

Date Code Title Description
AS Assignment

Owner name: CONAX AS, NORWAY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GRIMEN, GISLE;MOENCH, CHRISTIAN;SIGNING DATES FROM 20140304 TO 20140323;REEL/FRAME:032731/0158

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION