US20120082311A1 - Content protection using block reordering - Google Patents

Content protection using block reordering Download PDF

Info

Publication number
US20120082311A1
US20120082311A1 US13/316,784 US201113316784A US2012082311A1 US 20120082311 A1 US20120082311 A1 US 20120082311A1 US 201113316784 A US201113316784 A US 201113316784A US 2012082311 A1 US2012082311 A1 US 2012082311A1
Authority
US
United States
Prior art keywords
content item
reordered
content
block
reordering
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
US13/316,784
Inventor
Oleg Rashkovskiy
Eric C. Hannah
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to US13/316,784 priority Critical patent/US20120082311A1/en
Publication of US20120082311A1 publication Critical patent/US20120082311A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • 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/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/41Structure of client; Structure of client peripherals
    • H04N21/426Internal components of the client ; Characteristics thereof
    • H04N21/42684Client identification by a unique number or address, e.g. serial number, MAC address, socket ID
    • 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/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/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
    • H04N21/2351Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving encryption of additional data
    • 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/435Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H04N21/4353Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream involving decryption of additional data

Definitions

  • the present invention relates generally to data security, and more specifically to a technique for protecting digital content by reordering blocks of a data set.
  • Various types of data are transmitted or otherwise transferred from one entity, such as a. server, to another entity, such as a client computer or a television set-top box, via various communication paths such as broadcast, wireless, cable, modem, LAN, DSL, CD-ROM “sneakernet”, and so forth.
  • the content of such data transmissions may be, for example, digital video, digital audio, database, graphics, spreadsheet, text, or any other form of content.
  • the content may contain a movie, a song, a book, a television show, an electronic programming guide (EPG), an advertisement, advanced television enhancement information (ATVEF), a digital gift certificate, a digital coupon, an executable file, a data file. or any other content whatsoever.
  • EPG electronic programming guide
  • ATVEF advanced television enhancement information
  • Content providers may desire to prevent corruption and/or piracy of their content, not only during transmission but also thereafter during such time as the content is stored at the receiving entity.
  • One mechanism commonly employed to protect content is encryption, in which the digital values within the content are altered according to a cipher prior to their transmission.
  • Many encryption schemes and methodologies are well known in the art, and will not be discussed in detail in this patent. It is assumed that the skilled reader is familiar with the relevant art.
  • Some content may be so valuable that, in the example of a computer, it is not only desirable to protect the content which is stored on the hard drive, but further to prevent snooping attacks directed against internal wires, electromagnetic emanations from the keyboard and CRT, and so forth, on occasion even including the use of self-detonating chips which destroy themselves and their contents if someone attempts to break them open to peer inside with an electron microscope.
  • some content may be adequately protected if it is simply protected against software attacks such as those done via debuggers or memory dumps.
  • FIG. 1 shows one embodiment of a system which employs this invention, including a server and a client.
  • FIG. 2A shows how content is stored according to the prior art.
  • FIG. 2B shows how one type of file system operates according to the prior art, such as may be used in a system which operates as shown in FIG. 2A .
  • FIG. 3A shows how content is stored according to one embodiment of this invention, in which blocks of respective files are reordered within the separate storage areas allocated to such files.
  • FIG. 3B shows how a file system may operate according to the embodiment of this invention illustrated in FIG. 3A .
  • FIG. 3C shows a data handle table which may be utilized by another embodiment of a file system which operates according to the principles of FIG. 3A .
  • FIG. 4A shows how content is stored according to another embodiment of this invention, in which blocks of files are reordered within the overall storage space.
  • FIG. 4B shows how a file system may operate according to the embodiment illustrated in FIG. 4A .
  • FIG. 4C shows a data handle table for a file system which operates as illustrated in FIG. 4A .
  • FIG. 5 illustrates a recordable medium having disposed thereon one or more reordered content items.
  • FIG. 1 shows a system 50 including a Server in communication with a Client.
  • a Server in communication with a Client.
  • FIG. 1 shows a system 50 including a Server in communication with a Client.
  • the Server contains or has access to some Original Content which is desired to protect against attack. Rather than transmit the Original Content in its unsecured form to the Client (because the Original Content could be intercepted along its transmission path), the Server performs operations upon the Original Content to create Reordered Content. This may optionally be done in conjunction with conventional encryption, but it is not necessary.
  • blocks of the Original Content are rearranged according to an algorithm.
  • the algorithm employs a random number generator (not shown) to select reordered positions for blocks. In one embodiment, it may further select a block size using the random number generator. A predetermined reordering pattern could be employed, but a more non-deterministic scheme may offer greater security.
  • the reordering scheme may be employed to permit a single, specified client to utilize the transmitted content, while blocking access by all others—for example, a cable operator may wish to permit only a specified, individual, fee-paying client to view a particular pay-per-view movie (or rather, a particular reordered version thereof).
  • the reordering scheme may be employed to permit a multitude of clients to utilize the transmitted content while preventing others from utilizing it—for example, in a cable television system in which a common coaxial cable network is shared by a plurality of cable television operators, each operator may wish to permit any and all of its own subscribers to view a particular movie, while preventing the other cable operators' subscribers from viewing it.
  • the blocks which are being rearranged may be the same size, or they may vary in size. Same size lends itself to simpler processing, while varying size may lend itself to improved security.
  • the Client is shown as containing a Client ID.
  • This could be a unique identifier such as a serial number, or it could be a possibly-unique identifier such as a random prime number or the like.
  • the Client ID could be unique to a group (such as all cable boxes provided by this cable operator, or all cable boxes provided by this cable operator to purchasers of a certain subscription level).
  • the Server may contain a copy of each Client's Client ID.
  • the Server can simply keep a list of Client IDs as new Clients are provisioned by the Server; alternatively, the Client could communicate its Client ID to the Server under a public-key encrypted and certificate-verified dialog.
  • the Client ID could be a permanent feature of the individual Client, or it could be e.g. a session key generated by the client and securely communicated to the Server by known data security means.
  • the Server uses a Key Generator to produce a reordering Key.
  • a Reorderer takes as input the Original Content, and, in a manner dictated by the reordering Key, generates the Reordered Content.
  • Different Clients may have different Client IDs, with the result that for the same Original Content, their respective Reordered Content may well be in different orders and neither Client will be able to restore the Original Content from the other's Reordered Content.
  • the Server may include a Transmitter which sends the Reordered Content to the Client over a Reordered Content Channel of a communication medium.
  • the Transmitter may also send the Key to the Client over a Key Channel of the same or a different communication medium.
  • the Reordered Content and/or Key can he written to a storage medium (such as in FIG. 6 ) and delivered to the Client manually.
  • the Client contains Storage where the Reordered Content is stored.
  • This may be a hard drive, an optical drive, semiconductor memory, or any other suitable storage means.
  • the Reordered Content may be stored in a read-once manner, or it may be stored in a cache replacement manner until it is eventually evicted, or it may be stored permanently, or according to whatever storage needs the application dictates.
  • the Client contains a Key Generator which generates a Local Key as a function of the Client ID, in a manner corresponding to the generation of the Reordering Key by the Server,
  • the Local Key is the functional inverse of the Reordering Key.
  • the Local Key can be generated by the Server and transmitted over the Key Channel to the Client; in this case, the Client will not need a Key Generator.
  • the Local Key is used repeatedly for all content received from the Server.
  • each content item such as each respective movie. may have its own Local Key generated according to the Client ID and some other input such as a timestamp or a value from the content itself.
  • the Client further contains a Reorder Structure Generator which utilizes the Local Key to create a Block Reordering Structure, which is in turn used by a Content retriever to access the Reordered Content according to its original order for use by a Content User. Note that this does not necessarily mean that the Reordered Content must be accessed in linear fashion; the Block Reordering Structure may permit random access, as well.
  • the Content Retriever may be, for example, a hardware disk drive controller.
  • the Content User may be, for example, a software process or task spawned to display the movie.
  • the Client ID, Local Key, and/or Block Reordering Structure may be kept in Protected Memory.
  • OS operating system
  • OS operating system
  • Those technologies arc well-known, and may be utilized in practicing this invention, but it is not necessary to discuss their particulars here.
  • FIG. 2A illustrates how content may be stored in a storage device (generally analogous to the Client's Storage in FIG. 1 ) according to the prior art.
  • a storage device generally analogous to the Client's Storage in FIG. 1
  • two separate content items are shown stored in the storage—one containing “MOVIE” and one containing “GUIDE”.
  • MOVIE mobile Integrated Multimedia Extensions
  • GUI GUI-graphical user interface
  • the storage there are multiple storage location blocks, generally illustrated by locations 0 to 15 in FIG. 2A .
  • the first content item, “MOVIE”, is illustrated as being stored in contiguous locations 2 - 6 .
  • the second content item, “GUIDE”, is illustrated as being stored in non-contiguous locations 9 - 12 , 15 .
  • a content item such as a data file is not necessarily stored in contiguous physical locations, nor, indeed, in sequential physical locations. In such applications, the operating system or other control entity will keep track of where each logical block is physically stored. However, even in logically-addressed systems, the contents of a file are stored in linear fashion within that file's allocated storage.
  • FIG. 2B represents the addressing scheme itself, employed by the operating system.
  • Content item A (“MOVIE”) is stored in blocks 2 - 6 and content item B (“GUIDE”) is stored in blocks 9 - 12 , 14 , which the file system keeps track of via a linked list or other known method.
  • MOVIE Content item A
  • GUI content item B
  • FIG. 3A illustrates one difference between this invention and the prior art.
  • the same addressing scheme is employed in FIG. 3A as in FIG. 2A .
  • the Storage in FIG. 3A contains reordered content: the “MOVIE” content item has been reordered “VIMEO”, and the “GUIDE” content item has been reordered “DEUGI”.
  • the reordering of the content is orthogonal to the addressing scheme of the storage device.
  • FIG. 3B shows one embodiment of the Block Reordering Structure (of FIG. 1 ), in which linked lists are employed, to keep track of the reordered blocks of the stored content items.
  • the Reorder Structure Generator has generated a structure indicating that the blocks of the content item A (“MOVIE”) have been reordered such that the correct order is to retrieve the blocks from blocks 2 , 4 , 0 , 1 , and 3 in order; this is, of course, on top of any logical-to-physical addressing scheme employed. If the scheme of FIGS.
  • the initial (0 th ) block of “MOVIE” is found by the Content Retriever accessing the initial (0 th ) value (“2”) from the respective portion (“A”) of the Block Reordering Structure. then the operating system or other such entity will use this as an index (loosely speaking) into the File Structure, and will retrieve the physical location (“4”) where that block (“M”) is stored in the Storage device.
  • the scheme works that way for any N th block, of course. And it works that way for other content items' retrieval, as well (such as item B, “GUIDE”).
  • FIG. 3C shows an alternative embodiment of a Block Reordering Structure, in which it is a Data Handle Table, rather than a linked list.
  • the Data Handle Table which could be a content-addressable memory for example, the locations of the reordered blocks are recorded in what is illustrated as the rightmost column.
  • the locations of the reordered blocks are recorded in what is illustrated as the rightmost column.
  • one suitable option may simply be to record the corresponding values in what is illustrated as the center column.
  • the Client is to store more than one reordered content item at a time.
  • the leftmost column could be removed and could be replaced with a functionally similar scheme such as a table which includes one entry per content item, plus an index into the two-column Data Handle Table indicating the first entry for that content item, and that it could further include either an indication of how many sequential entries in the Data Handle Table belong to that content item, or an index to the final entry in the Data. Handle Table for that content item.
  • center column could be removed in some embodiments, and the functionality of its contents could be replaced by logic which indexes into the rightmost column based on the logical block position of a desired block.
  • OS File System or other such entity performing logical-to-physical address translation to produce Physical Addresses that are used to directly address the Storage medium.
  • FIG. 4A illustrates an embodiment which does not use logical addressing, and in which the Server has direct control over where in the Client's physically addressed Storage device Reordered Content items are stored.
  • the values stored in the Block Reordering Structure are physical addresses.
  • FIG. 4B illustrates how the file system may operate in controlling storage according to the physically-addressed, storage-wide reordering shown in FIG. 4A .
  • FIG. 4C illustrates an alternative embodiment in which the physical addresses arc stored in a Data Handle Table rather than in a linked list.
  • the reader will understand that the functionality of this table may be distributed in a manner similar to that discussed above regarding FIG. 3C .
  • FIG. 5 illustrates a recordable medium having recorded thereon one or more block-reordered content items.
  • This may be the storage device in the server, wherein is stored a reordered content item prior to or during transmission to a client.
  • it may be the storage device in the client which has received the reordered content item from the server.
  • it may be the transmission medium itself, in the ease of a sneakernet delivery mechanism.
  • it could be an archival storage mechanism.

Abstract

An apparatus and method for protecting a content item such as a digitally encoded movie, an electronic programming guide, or the like, by reordering blocks of the content item prior to transmitting it to a receiving device. The receiving device constructs a block reordering structure which is used to access the reordered content item, to facilitate retrieval of a desired block from the original content item. The reordering may be done responsive to an identifier value of the receiving device, such as a serial number.

Description

  • This application is a divisional of U.S. patent application Ser. No. 09/706,501, filed on Nov. 2, 2000.
  • BACKGROUND OF THE INVENTION
  • 1. Technical Field of the Invention
  • The present invention relates generally to data security, and more specifically to a technique for protecting digital content by reordering blocks of a data set.
  • 2. Background Art
  • Various types of data are transmitted or otherwise transferred from one entity, such as a. server, to another entity, such as a client computer or a television set-top box, via various communication paths such as broadcast, wireless, cable, modem, LAN, DSL, CD-ROM “sneakernet”, and so forth. The content of such data transmissions may be, for example, digital video, digital audio, database, graphics, spreadsheet, text, or any other form of content. The content may contain a movie, a song, a book, a television show, an electronic programming guide (EPG), an advertisement, advanced television enhancement information (ATVEF), a digital gift certificate, a digital coupon, an executable file, a data file. or any other content whatsoever. When this patent discusses examples such as a cable television company server sending an EPG to a subscriber's set-top box, the reader will understand that the invention is not necessarily limited to the specific example given, but rather that the example is given to help the reader understand the invention.
  • Content providers may desire to prevent corruption and/or piracy of their content, not only during transmission but also thereafter during such time as the content is stored at the receiving entity. One mechanism commonly employed to protect content is encryption, in which the digital values within the content are altered according to a cipher prior to their transmission. Many encryption schemes and methodologies are well known in the art, and will not be discussed in detail in this patent. It is assumed that the skilled reader is familiar with the relevant art.
  • It is also well understood that encryption of a large data set, such as a full-length movie, requires a relatively large amount of computational power and time, and that not all applications lend themselves to expense of power and/or time. This may be especially true of content which has limited economic value or which has a sufficiently short useful lifetime. The lower the value of the content, and the shorter its useful lifetime, the less justification there may be for using expensive encryption technologies to protect that content.
  • It is also understood that there may be many avenues of attack against content protection, with different levels of risk. Content may be attacked by different sets of actors using different sets of tools. In general, the easier and less expensive the attack, the larger the set of people who will be engaged in it. For some types of content, it may not be necessary—economically or otherwise—to protect content against all types of attack by all classes of people. For example, while the owner of a major motion picture may deem it necessary to provide strong encryption on every byte of the content at all stages of transmission and storage, the owner of an electronic programming guide covering only the next few days' broadcasts may deem it sufficient to use a weaker (and less costly) protection mechanism.
  • Some content, such as perhaps a nation's military secrets, may be so valuable that, in the example of a computer, it is not only desirable to protect the content which is stored on the hard drive, but further to prevent snooping attacks directed against internal wires, electromagnetic emanations from the keyboard and CRT, and so forth, on occasion even including the use of self-detonating chips which destroy themselves and their contents if someone attempts to break them open to peer inside with an electron microscope. On the other end of the spectrum, some content may be adequately protected if it is simply protected against software attacks such as those done via debuggers or memory dumps.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The invention will be understood more fully from the detailed description given below and from the accompanying drawings of embodiments of the invention which, however, should not be taken to limit the invention to the specific embodiments described, but are for explanation and understanding only.
  • FIG. 1 shows one embodiment of a system which employs this invention, including a server and a client.
  • FIG. 2A shows how content is stored according to the prior art.
  • FIG. 2B shows how one type of file system operates according to the prior art, such as may be used in a system which operates as shown in FIG. 2A.
  • FIG. 3A shows how content is stored according to one embodiment of this invention, in which blocks of respective files are reordered within the separate storage areas allocated to such files.
  • FIG. 3B shows how a file system may operate according to the embodiment of this invention illustrated in FIG. 3A.
  • FIG. 3C shows a data handle table which may be utilized by another embodiment of a file system which operates according to the principles of FIG. 3A.
  • FIG. 4A shows how content is stored according to another embodiment of this invention, in which blocks of files are reordered within the overall storage space.
  • FIG. 4B shows how a file system may operate according to the embodiment illustrated in FIG. 4A.
  • FIG. 4C shows a data handle table for a file system which operates as illustrated in FIG. 4A.
  • FIG. 5 illustrates a recordable medium having disposed thereon one or more reordered content items.
  • DETAILED DESCRIPTION
  • FIG. 1 shows a system 50 including a Server in communication with a Client. As mentioned above, these are only illustrative examples, and the invention is not limited to server/client applications.
  • The Server contains or has access to some Original Content which is desired to protect against attack. Rather than transmit the Original Content in its unsecured form to the Client (because the Original Content could be intercepted along its transmission path), the Server performs operations upon the Original Content to create Reordered Content. This may optionally be done in conjunction with conventional encryption, but it is not necessary.
  • In these operations performed by the Server, blocks of the Original Content are rearranged according to an algorithm. In one embodiment, the algorithm employs a random number generator (not shown) to select reordered positions for blocks. In one embodiment, it may further select a block size using the random number generator. A predetermined reordering pattern could be employed, but a more non-deterministic scheme may offer greater security.
  • In some applications, the reordering scheme may be employed to permit a single, specified client to utilize the transmitted content, while blocking access by all others—for example, a cable operator may wish to permit only a specified, individual, fee-paying client to view a particular pay-per-view movie (or rather, a particular reordered version thereof). In other applications, the reordering scheme may be employed to permit a multitude of clients to utilize the transmitted content while preventing others from utilizing it—for example, in a cable television system in which a common coaxial cable network is shared by a plurality of cable television operators, each operator may wish to permit any and all of its own subscribers to view a particular movie, while preventing the other cable operators' subscribers from viewing it.
  • The blocks which are being rearranged may be the same size, or they may vary in size. Same size lends itself to simpler processing, while varying size may lend itself to improved security.
  • In FIG. 1, the Client is shown as containing a Client ID. This could be a unique identifier such as a serial number, or it could be a possibly-unique identifier such as a random prime number or the like. Alternatively, the Client ID could be unique to a group (such as all cable boxes provided by this cable operator, or all cable boxes provided by this cable operator to purchasers of a certain subscription level).
  • In some embodiments, the Server may contain a copy of each Client's Client ID. For example, the Server can simply keep a list of Client IDs as new Clients are provisioned by the Server; alternatively, the Client could communicate its Client ID to the Server under a public-key encrypted and certificate-verified dialog. The Client ID could be a permanent feature of the individual Client, or it could be e.g. a session key generated by the client and securely communicated to the Server by known data security means.
  • Once the Server is in possession of the Client ID, it uses a Key Generator to produce a reordering Key. A Reorderer takes as input the Original Content, and, in a manner dictated by the reordering Key, generates the Reordered Content. Different Clients may have different Client IDs, with the result that for the same Original Content, their respective Reordered Content may well be in different orders and neither Client will be able to restore the Original Content from the other's Reordered Content.
  • The Server may include a Transmitter which sends the Reordered Content to the Client over a Reordered Content Channel of a communication medium. The Transmitter may also send the Key to the Client over a Key Channel of the same or a different communication medium. Alternatively, the Reordered Content and/or Key can he written to a storage medium (such as in FIG. 6) and delivered to the Client manually.
  • The Client contains Storage where the Reordered Content is stored. This may be a hard drive, an optical drive, semiconductor memory, or any other suitable storage means. The Reordered Content may be stored in a read-once manner, or it may be stored in a cache replacement manner until it is eventually evicted, or it may be stored permanently, or according to whatever storage needs the application dictates.
  • In one embodiment, the Client contains a Key Generator which generates a Local Key as a function of the Client ID, in a manner corresponding to the generation of the Reordering Key by the Server, The Local Key is the functional inverse of the Reordering Key. In other embodiments, the Local Key can be generated by the Server and transmitted over the Key Channel to the Client; in this case, the Client will not need a Key Generator.
  • In some embodiments, the Local Key is used repeatedly for all content received from the Server. In other embodiments. each content item, such as each respective movie. may have its own Local Key generated according to the Client ID and some other input such as a timestamp or a value from the content itself. There is no strict requirement that the same reordering key be used for an entire logical content item; in some embodiments, it may be desirable to switch keys one or more times during reordering of a lengthy content item. This may improve security, without unduly increasing system complexity.
  • The Client further contains a Reorder Structure Generator which utilizes the Local Key to create a Block Reordering Structure, which is in turn used by a Content Retriever to access the Reordered Content according to its original order for use by a Content User. Note that this does not necessarily mean that the Reordered Content must be accessed in linear fashion; the Block Reordering Structure may permit random access, as well. The Content Retriever may be, for example, a hardware disk drive controller. The Content User may be, for example, a software process or task spawned to display the movie.
  • For improved security, the Client ID, Local Key, and/or Block Reordering Structure may be kept in Protected Memory. In some applications, it may be sufficient that this memory be protected by conventional operating system (OS) schemes whereby one process can be denied access to another process's memory area. In other applications, it may be necessary to take further protective measures. such as by using self-destructive memory devices for the Protected Memory to prevent them being read via means more intrusive than mere software attacks. It may also be necessary to protect busses, wires, and other points of potential physical attack. It may be desirable to prevent physical access such as by burying the protected memory in a layer of plastic. Those technologies arc well-known, and may be utilized in practicing this invention, but it is not necessary to discuss their particulars here.
  • FIG. 2A illustrates how content may be stored in a storage device (generally analogous to the Client's Storage in FIG. 1) according to the prior art. In the example shown, two separate content items are shown stored in the storage—one containing “MOVIE” and one containing “GUIDE”. The reader will understand that these content items are not necessarily textual, and that the respective blocks of each do not necessarily contain only a single byte value. These simplistic examples are shown merely for illustrative purposes.
  • In the storage, there are multiple storage location blocks, generally illustrated by locations 0 to 15 in FIG. 2A. The first content item, “MOVIE”, is illustrated as being stored in contiguous locations 2-6. The second content item, “GUIDE”, is illustrated as being stored in non-contiguous locations 9-12, 15. In many common applications, such as a personal computer, a content item such as a data file is not necessarily stored in contiguous physical locations, nor, indeed, in sequential physical locations. In such applications, the operating system or other control entity will keep track of where each logical block is physically stored. However, even in logically-addressed systems, the contents of a file are stored in linear fashion within that file's allocated storage.
  • FIG. 2B represents the addressing scheme itself, employed by the operating system. Content item A (“MOVIE”) is stored in blocks 2-6 and content item B (“GUIDE”) is stored in blocks 9-12,14, which the file system keeps track of via a linked list or other known method.
  • FIG. 3A illustrates one difference between this invention and the prior art. The same addressing scheme is employed in FIG. 3A as in FIG. 2A. However, the Storage in FIG. 3A contains reordered content: the “MOVIE” content item has been reordered “VIMEO”, and the “GUIDE” content item has been reordered “DEUGI”. The reordering of the content is orthogonal to the addressing scheme of the storage device.
  • FIG. 3B shows one embodiment of the Block Reordering Structure (of FIG. 1), in which linked lists are employed, to keep track of the reordered blocks of the stored content items. In accordance with the Client's ID and thus the Local Key (of FIG. 1), the Reorder Structure Generator has generated a structure indicating that the blocks of the content item A (“MOVIE”) have been reordered such that the correct order is to retrieve the blocks from blocks 2, 4, 0, 1, and 3 in order; this is, of course, on top of any logical-to-physical addressing scheme employed. If the scheme of FIGS. 3A and 3B is employed, the initial (0th) block of “MOVIE” is found by the Content Retriever accessing the initial (0th) value (“2”) from the respective portion (“A”) of the Block Reordering Structure. then the operating system or other such entity will use this as an index (loosely speaking) into the File Structure, and will retrieve the physical location (“4”) where that block (“M”) is stored in the Storage device. The scheme works that way for any Nth block, of course. And it works that way for other content items' retrieval, as well (such as item B, “GUIDE”).
  • FIG. 3C shows an alternative embodiment of a Block Reordering Structure, in which it is a Data Handle Table, rather than a linked list. In the Data Handle Table, which could be a content-addressable memory for example, the locations of the reordered blocks are recorded in what is illustrated as the rightmost column. There needs to be some mechanism of associating these reordered locations with their regularly-ordered counterparts: one suitable option may simply be to record the corresponding values in what is illustrated as the center column. Finally, if the Client is to store more than one reordered content item at a time. there needs to he some mechanism of associating these ordered/reordered value pairs with the content item to which they pertain; one suitable option may be to record an identifier of the respective content item in what is illustrated as the leftmost column. Those skilled in the art will readily appreciate that other embodiments are within their understanding, when armed with this disclosure. For example, the leftmost column could be removed and could be replaced with a functionally similar scheme such as a table which includes one entry per content item, plus an index into the two-column Data Handle Table indicating the first entry for that content item, and that it could further include either an indication of how many sequential entries in the Data Handle Table belong to that content item, or an index to the final entry in the Data. Handle Table for that content item. Furthermore, the center column could be removed in some embodiments, and the functionality of its contents could be replaced by logic which indexes into the rightmost column based on the logical block position of a desired block. Finally, it should be understood that if a logical addressing scheme is employed, there will be an OS File System or other such entity performing logical-to-physical address translation to produce Physical Addresses that are used to directly address the Storage medium.
  • FIG. 4A illustrates an embodiment which does not use logical addressing, and in which the Server has direct control over where in the Client's physically addressed Storage device Reordered Content items are stored. In such a scheme, the values stored in the Block Reordering Structure are physical addresses.
  • FIG. 4B illustrates how the file system may operate in controlling storage according to the physically-addressed, storage-wide reordering shown in FIG. 4A.
  • FIG. 4C illustrates an alternative embodiment in which the physical addresses arc stored in a Data Handle Table rather than in a linked list. The reader will understand that the functionality of this table may be distributed in a manner similar to that discussed above regarding FIG. 3C.
  • FIG. 5 illustrates a recordable medium having recorded thereon one or more block-reordered content items. This may be the storage device in the server, wherein is stored a reordered content item prior to or during transmission to a client. Or, it may be the storage device in the client which has received the reordered content item from the server. Or, it may be the transmission medium itself, in the ease of a sneakernet delivery mechanism. Or, it could be an archival storage mechanism.
  • Reference in this specification to “an embodiment,” “one embodiment,” “some embodiments,” or “other embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least some embodiments, but not necessarily all embodiments, of the invention. The various appearances “an embodiment,” “one embodiment,” or “some embodiments” are not necessarily all referring to the same embodiments.
  • If the specification states a component, feature, structure, or characteristic “may”, “might”, or “could” be included, that particular component, feature, structure, or characteristic is not required to be included. If the specification or claim refers to “a” or “an” element, that does not mean there is only one of the element. If the specification or claims refer to “an additional” element, that does not preclude there being more than one of the additional element.
  • Those skilled in the art having the benefit of this disclosure will appreciate that many other variations from the foregoing description and drawings may be made within the scope of the present invention. Indeed, the invention is not limited to the details described above. Rather, it is the following claims including any amendments thereto that define the scope of the invention.

Claims (11)

1. A cable set-top box comprising:
protected memory which is adapted for storing, a substantially unique identifier value, a local key, and a block reordering structure:
a storage device which is adapted for storing a reordered content item;
a reorder structure generator adapted to create the block reordering structure according to the local key; and
a content retriever adapted to fetch blocks of the reordered content item according to the block reordering structure.
2. The cable set-top box of claim 1 wherein:
the reordered content item is a first reordered content item and the storage device is further for storing a second reordered content item;
the first reordered content item comprises an electronic programming guide: and
the second reordered content item is a video content item.
3. A method of protecting an original content item which has blocks in an original order, comprising:
reordering blocks of the original content item in a new order which is different than the original order, according to an identifier value of an intended recipient; and
writing the reordered blocks to either storage or a communication channel in the new order.
4. The method of claim 3 wherein the intended recipient comprises a set-top box and the identifier value comprises a serial number of the set-top box.
5. The method of claim 4 further comprising a server maintaining a list of respective serial numbers of a plurality of set-top boxes.
6. The method of claim 5 further comprising the server reordering and writing the blocks in a unique order for each of two or more of the set-top boxes which have unique serial numbers.
7. A method of accessing a content item by an intended recipient having an identifier value, wherein the content item includes a block having an original order position and a new order position which is different than the original order position, the method comprising:
storing an identification of a relationship between the original order position and the new order position of the block; and
accessing the block by using the stored relationship identification to retrieve the block from the new order position in response to a request to retrieve it from the original order position.
8. The method of claim 7 wherein the intended recipient is a set-top box and the method further comprises generating the identification of the relationship according to an identifying, value of the set-top box.
9. The method of claim 8 wherein the identifying value comprises a serial number.
10. The method of claim 8 wherein the identifying value comprises a random number.
11. The method of claim 8 wherein the identifying value comprises a session key.
US13/316,784 2000-11-02 2011-12-12 Content protection using block reordering Abandoned US20120082311A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/316,784 US20120082311A1 (en) 2000-11-02 2011-12-12 Content protection using block reordering

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/706,501 US8281155B1 (en) 2000-11-02 2000-11-02 Content protection using block reordering
US13/316,784 US20120082311A1 (en) 2000-11-02 2011-12-12 Content protection using block reordering

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/706,501 Division US8281155B1 (en) 2000-11-02 2000-11-02 Content protection using block reordering

Publications (1)

Publication Number Publication Date
US20120082311A1 true US20120082311A1 (en) 2012-04-05

Family

ID=45889858

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/706,501 Expired - Fee Related US8281155B1 (en) 2000-11-02 2000-11-02 Content protection using block reordering
US13/316,773 Expired - Fee Related US8782437B2 (en) 2000-11-02 2011-12-12 Content protection using block reordering
US13/316,784 Abandoned US20120082311A1 (en) 2000-11-02 2011-12-12 Content protection using block reordering

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US09/706,501 Expired - Fee Related US8281155B1 (en) 2000-11-02 2000-11-02 Content protection using block reordering
US13/316,773 Expired - Fee Related US8782437B2 (en) 2000-11-02 2011-12-12 Content protection using block reordering

Country Status (1)

Country Link
US (3) US8281155B1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8281155B1 (en) * 2000-11-02 2012-10-02 Intel Corporation Content protection using block reordering
CN105657454A (en) * 2016-03-01 2016-06-08 四川九洲电器集团有限责任公司 Audio and video terminal network EPG receiving method and system
CN112001717A (en) * 2020-10-27 2020-11-27 四川泰立科技股份有限公司 Method, system and storage medium for calculating encryption currency of digital television

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9425825B2 (en) 2012-05-22 2016-08-23 International Business Machines Corporation Path encoding and decoding
US9639597B2 (en) 2012-10-30 2017-05-02 FHOOSH, Inc. Collecting and classifying user information into dynamically-updated user profiles
CN103093375A (en) * 2012-12-31 2013-05-08 邬国锐 Electronic coupon processing system and method
US10579823B2 (en) 2014-09-23 2020-03-03 Ubiq Security, Inc. Systems and methods for secure high speed data generation and access
CA2962432C (en) 2014-09-23 2023-04-18 FHOOSH, Inc. Secure high speed data storage, access, recovery, and transmission
CA2968084C (en) * 2014-12-15 2024-01-02 FHOOSH, Inc. Systems and methods for diffracted data retrieval
GB2533391A (en) 2014-12-19 2016-06-22 Ibm Wall encoding and decoding
GB2533393A (en) 2014-12-19 2016-06-22 Ibm Pad encoding and decoding
GB2533392A (en) 2014-12-19 2016-06-22 Ibm Path encoding and decoding
IL236440A0 (en) * 2014-12-24 2015-04-30 Cisco Tech Inc Shuffled media content
US9950261B2 (en) 2016-04-29 2018-04-24 International Business Machines Corporation Secure data encoding for low-resource remote systems
CN107484032B (en) * 2017-09-08 2018-08-03 武汉斗鱼网络科技有限公司 Prevent the verification method brushed and device
US11349656B2 (en) 2018-03-08 2022-05-31 Ubiq Security, Inc. Systems and methods for secure storage and transmission of a data stream
EP3681094B1 (en) * 2019-01-09 2021-11-10 British Telecommunications public limited company Impeding data access

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5566189A (en) * 1994-08-31 1996-10-15 Hughes Aircraft Co. Method and device for puncturing data
US5926610A (en) * 1995-11-15 1999-07-20 Sony Corporation Video data processing method, video data processing apparatus and video data recording and reproducing apparatus
US6012144A (en) * 1996-10-08 2000-01-04 Pickett; Thomas E. Transaction security method and apparatus
US6070154A (en) * 1998-11-27 2000-05-30 Activepoint Ltd. Internet credit card security
US20070204115A1 (en) * 2006-02-28 2007-08-30 Maven Networks, Inc. Systems and methods for storage shuffling techniques to download content to a file
US20070237151A1 (en) * 2002-11-14 2007-10-11 Vic Alfano Reordering Sequence Based Channels
US7603336B2 (en) * 2005-12-19 2009-10-13 International Business Machines Corporation Peephole DBMS reorganization allowing concurrent data manipulation
US7698560B2 (en) * 2002-04-11 2010-04-13 Spitlock Holdings Pty Ltd Information storage system
US7753265B2 (en) * 2004-07-12 2010-07-13 Harris Intellectual Property, Lp System and method for securing a credit account

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5297207A (en) * 1993-05-24 1994-03-22 Degele Steven T Machine generation of cryptographic keys by non-linear processes similar to processes normally associated with encryption of data
US6577734B1 (en) * 1995-10-31 2003-06-10 Lucent Technologies Inc. Data encryption key management system
WO1998047259A2 (en) * 1997-03-10 1998-10-22 Fielder Guy L File encryption method and system
US6061449A (en) * 1997-10-10 2000-05-09 General Instrument Corporation Secure processor with external memory using block chaining and block re-ordering
US6185679B1 (en) * 1998-02-23 2001-02-06 International Business Machines Corporation Method and apparatus for a symmetric block cipher using multiple stages with type-1 and type-3 feistel networks
US6490353B1 (en) * 1998-11-23 2002-12-03 Tan Daniel Tiong Hok Data encrypting and decrypting apparatus and method
US6415032B1 (en) * 1998-12-01 2002-07-02 Xilinx, Inc. Encryption technique using stream cipher and block cipher
US7054445B2 (en) * 2000-03-31 2006-05-30 Vdg, Inc. Authentication method and schemes for data integrity protection
AU2001271704A1 (en) * 2000-06-29 2002-01-14 Cachestream Corporation Digital rights management
US8281155B1 (en) * 2000-11-02 2012-10-02 Intel Corporation Content protection using block reordering
EP1217541A1 (en) * 2000-11-29 2002-06-26 Lafayette Software Inc. Method of processing queries in a database system, and database system and software product for implementing such method
US7549147B2 (en) * 2002-04-15 2009-06-16 Core Sdi, Incorporated Security framework for protecting rights in computer software
US7599490B2 (en) * 2004-03-03 2009-10-06 Harris Corporation Method and apparatus for data encryption
US7873982B2 (en) * 2006-06-22 2011-01-18 Tivo Inc. Method and apparatus for creating and viewing customized multimedia segments
US20090169001A1 (en) * 2007-12-28 2009-07-02 Cisco Technology, Inc. System and Method for Encryption and Secure Transmission of Compressed Media
JP4952627B2 (en) * 2008-03-21 2012-06-13 富士通株式会社 Image processing apparatus, image processing method, and image processing program
US8204217B2 (en) * 2009-01-28 2012-06-19 Telefonaktiebolaget Lm Ericsson (Publ) Lightweight streaming protection by sequence number scrambling

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5566189A (en) * 1994-08-31 1996-10-15 Hughes Aircraft Co. Method and device for puncturing data
US5926610A (en) * 1995-11-15 1999-07-20 Sony Corporation Video data processing method, video data processing apparatus and video data recording and reproducing apparatus
US6012144A (en) * 1996-10-08 2000-01-04 Pickett; Thomas E. Transaction security method and apparatus
US6070154A (en) * 1998-11-27 2000-05-30 Activepoint Ltd. Internet credit card security
US7698560B2 (en) * 2002-04-11 2010-04-13 Spitlock Holdings Pty Ltd Information storage system
US8090953B2 (en) * 2002-04-11 2012-01-03 Splitlock Holdings Pty Ltd. Information storage system
US20070237151A1 (en) * 2002-11-14 2007-10-11 Vic Alfano Reordering Sequence Based Channels
US7753265B2 (en) * 2004-07-12 2010-07-13 Harris Intellectual Property, Lp System and method for securing a credit account
US8074879B2 (en) * 2004-07-12 2011-12-13 Harris Intellectual Property, Lp System and method for securing a credit account
US7603336B2 (en) * 2005-12-19 2009-10-13 International Business Machines Corporation Peephole DBMS reorganization allowing concurrent data manipulation
US20070204115A1 (en) * 2006-02-28 2007-08-30 Maven Networks, Inc. Systems and methods for storage shuffling techniques to download content to a file

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8281155B1 (en) * 2000-11-02 2012-10-02 Intel Corporation Content protection using block reordering
CN105657454A (en) * 2016-03-01 2016-06-08 四川九洲电器集团有限责任公司 Audio and video terminal network EPG receiving method and system
CN112001717A (en) * 2020-10-27 2020-11-27 四川泰立科技股份有限公司 Method, system and storage medium for calculating encryption currency of digital television

Also Published As

Publication number Publication date
US8281155B1 (en) 2012-10-02
US8782437B2 (en) 2014-07-15
US20120082310A1 (en) 2012-04-05

Similar Documents

Publication Publication Date Title
US8782437B2 (en) Content protection using block reordering
US7845015B2 (en) Public key media key block
EP1408497A1 (en) Method of protecting recorded multimedia content against unauthorized duplication
KR101138632B1 (en) Method and system of external data storage
US7111005B1 (en) Method and apparatus for automatic database encryption
KR101067566B1 (en) Use of media storage structure with multiple pieces of content in a content-distribution system
US7003675B2 (en) Encrypted content data structure package and generation thereof
US8473742B2 (en) Method of distributing a decryption key in fixed-content data
US20020042859A1 (en) Method and system for privatizing computer data
US7315859B2 (en) Method and apparatus for management of encrypted data through role separation
AU2002213436A1 (en) Method and apparatus for automatic database encryption
US20060129801A1 (en) Method and device of data encryption
US8200964B2 (en) Method and apparatus for accessing an encrypted file system using non-local keys
US20090187772A1 (en) Tamper evidence per device protected identity
WO2003005175A2 (en) Multi-level, multi-dimensional content protection
US7391864B2 (en) Apparatus and method for hierarchical encryption
US20070174637A1 (en) System and method for assigning sequence keys to a media player to enable flexible traitor tracing
US20100293390A1 (en) Secure movie download
KR20020075379A (en) Method and apparatus for revocation list management using a contact list having a contact count field
JP4338185B2 (en) How to encrypt / decrypt files
WO1998003904A1 (en) Protection of database contents against use without permit
US20110197076A1 (en) Total computer security
KR20230086559A (en) Multi secure storage system and method of thereof

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

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