Abstract:
A computer based method and apparatus to tie content protection information to recipient devices via a family of deterministic permutations of quadratic multivariate polynomial maps used for computing an HMAC (Hash Message Authentication Code) or a signed digest. This allows digital rights management (DRM) systems to customize the protection information (such as an HMAC or signed digest) for audio and video content, whereby such protection information for a piece of content differs for different recipient devices or for types of recipient devices.

Description:
FIELD OF THE INVENTION 
     The present disclosure relates to storage methods for audio and video digital content, devices for using such methods, and systems for distributing such stored content. 
     BACKGROUND 
     Protection of digital content (such as audio and video) transferred between computers or computing devices over a network (such as the Internet) is fundamentally important for many enterprises today. Enterprises attempt to secure this protection by implementing some form of Digital Rights Management (DRM) process. The DRM process often involves encrypting the piece of content (e.g., encrypting the binary form of the content) thereby to restrict usage to those who have been granted a right to the content. Typically the encryption is provided at a central server and the content distributed to client devices. 
     Some of the rights to pieces of content that are distributed by existing DRM systems are permitted to be viewed on a certain number of distinct devices (i.e. platforms such as computers, computing devices, players, cell phones) simultaneously. For instance, one existing DRM system distributes certain recorded songs to both desktop computer systems and portable player devices using the same method. The method used does not take advantage of the increased performance of the desktop system to increase DRM protection. If the DRM encryption is broken for one of the two platforms, it can be used to break the DRM encryption on the other platform and on other instances of the same platform. Existing DRM systems thereby typically widely distribute content protected by only one digital rights protection mechanism. However, content providers would like to have their content viewed on different platforms and would like to maintain the integrity of the security measures while taking advantage of the differences in resources on the various recipient platforms. 
     However, the present inventors have recognized that existing DRM systems often do not allow the mechanism for decryption of protected content to vary based on the specific recipient device and device type. Allowing the authentication or verification (such as an HMAC or digest) to vary across devices and device types prevents a party that breaks the DRM security on one device or device type to break the DRM security on another device or device type. Furthermore, allowing different mechanisms for authentication to be used for different device types can allow the distributing party to choose use a mechanism more suited to the target device. Therefore the present inventors have identified a need for a DRM system that flexibly allows content distributors to set content protection mechanisms based on both the device and the device type. 
     SUMMARY 
     Accordingly, the present inventors have identified a need for a content distribution mechanism that can flexibly change the method of content protection according to both the specific device and the device type that the content is intended to be accessed by. This is accomplished by allowing the authentication or verification mechanism in the DRM system to vary across devices and device types. (These mechanisms are generically referred to here as “authentication.”) This method employs a parameterized family of transformations used to non-linearly transform a set of data in a flexible and customizable way. The basic parameters represent the size of a basic block of data, the number of blocks of data in the input and the number of blocks of data in the output. Each instance of the transformation, that is each member of the family, takes an input of the number of input blocks of the predetermined length and outputs the number of output blocks, of the same predetermined length, that have been transformed. The transformations are in one embodiment a set of multivariate polynomials of degree 2. The number of polynomial coefficients are in the range of 0 to 2 S-1 , where S is the number of bits per block. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of an apparatus for use in an exemplary protection process. 
         FIG. 2  is a block diagram of an apparatus for use in an exemplary user device process. 
     
    
    
     DETAILED DESCRIPTION 
     Exemplary embodiments of the invention are disclosed here in the context of cryptographic HMAC or digests. An HMAC (Hash Message Authentication Code) is conventionally calculated using a specific algorithm involving a cryptographic hash function with a secret key, from a message. It is used to verify the integrity and/or source of the message. Conventional functions such as MD5 or SHA-1 are used to calculate an HMAC. A digest is the result (output) of a one-way function, and is also referred to as a “message digest,” and is useful for message verification. The receiving device computes its own HMAC or digest from the received message, and matches that to the HMAC or digest value that accompanies the message. 
     The present system in one embodiment uses a parameterized family of transformations that non-linearly transform a set of data in a very flexible and customizable way for authentication. The basic set of parameters is designated here (S, lb, Ob) with ‘S’ representing the size of a basic block of data, ‘lb’ representing the number of blocks of data in the input to the transformation and ‘Ob’ representing the number of blocks of data in the transformation output. Each instance of the transformation thereby takes an input of lb blocks each of S bits and will output Ob blocks each of S bits that have been transformed. 
     Each of these transformations T is expressed here in one embodiment as a set of Ob multivariate polynomials in lb variables with coefficients from 0 to (2 S-1 ) and with degree two. This can be expressed as:
 
 T= ( T   1   ,T   2   , . . . ,T   ob )
 
     Each T i  is a multivariate polynomial in lb variables of degree two and coefficients in the range 0 to (2 S-1 ). When supplied with an input (data) X expressed as (x1, x2, . . . , xlb), the transformation T is applied as:
 
 T ( X )=( T   1 ( x 1, x 2, . . . , xlb ), . . . , T   ob ( x 1, x 2, . . . , xl )).
 
     If T i  is the polynomial written as: T i =a (1,1) *x1*x1+ . . . +a (i,j) *xi*xj+ . . . +a (lb,lb) *xlb*xlb, where a (i,j)  represents the polynomial coefficients then T i  is evaluated by applying an agreed upon (predetermined) notion of commutative addition and commutative multiplication to the set {0, . . . , 2 S-1 }. For example, if S=8, the coefficient octets could be used to represent elements of the Galois field GF (2 8 ), and addition and multiplication could be applied as defined in that field. 
     In another embodiment, one uses custom operations with non-traditional arithmetic such as a, b being elements of the set {1, 2 16 } and define a*b=a*b modulus (2 16 +1), and a+b=a+b modulus (2 16 +1) if a+b≠2 16 +1; otherwise a+b=a. 
     As an example of the parameters let (S, lb, Ob)=(8, 8, 8). A transformation T with such parameters would be described by 8 polynomials in 8 variables, each with 64 degree two coefficients represented by octets. These polynomials could be stored as an array of 8*8*64 octets and the associated arithmetic could be any addition and multiplication on 8 bits. Each transformation T i  would take 64 bits as input and provide 64 bits as output. 
     Many such transformations could be applied in sequence as long as parameter Ob of the first transformation equals the parameter lb for the next transform in the chain. One such transformation or a chain of such single transformations is used as one step in an HMAC used in a DRM mechanism. As noted above, HMAC functions inherently each have a key (since they are cryptographic.) The keys are predetermined and hard-coded in the DRM software. The key here is used to determine the polynomial coefficients. For example, the coefficients may be identical for each member of a type of devices, but are used differently, such as in a different order, for each individual device. The way they are used here is thereby determined by the HMAC key. 
     An advantage of this family of transformations is that they are very flexible and customizable. One feature of this family of transformations is that the arithmetic operations on a basic data block can be different for two different devices (platform). For instance, each individual device may have its own HMAC key derived, e.g., from the device. Furthermore, the mapping between the coefficients of the polynomials and the array of basic blocks representing them can be dependent on the particular user device (platform) implementing the DRM. This allows the table of polynomial coefficients to be fixed but the polynomials they represent may vary based on the platform that the associated content is to be accessed on, thereby providing a different key for performing the DRM digest operation on each recipient (user) device using a constant block of data. For instance, the polynomial may be arranged in a distinct order determined by a property of the device such as its serial number. In an example, if the device serial number is 22, the first byte would represent the 22nd coefficient, etc. 
     In another embodiment, different families of recipient (user) devices may use transformations having different parameters S, lb, ob. For device types that are more limited in computing power or memory (such as Smart cards or embedded consumer electronic devices), smaller values for lb and Ob may be used, requiring smaller tables of data. For device types with more computing power such as desktop computers the transformations can be chained, and larger values of S, lb and Ob may be used, providing increased complexity and security. this flexibility allows “chaining” of the polynomials, expressed logically as: Ib 1 →Ob 1 =&gt;Ib 2 →Ob 2 . 
     The flexibility allowed for choosing the parameters S, lb, Ob, and the arithmetic operations differently for different recipient devices provides beneficial properties that can be employed to provide different level DRM mechanisms per individual device and per device type. 
       FIG. 1  shows in block diagram form an apparatus  20  for accomplishing the transformation which is part of the DRM process, for instance part of an authentication process. This is typically carried out in the context of a DRM server operated by the content provider, or perhaps under his control, or perhaps under control of an on-line “store” (vendor) of on-line content, such as video and audio material. While this apparatus is shown in a block diagram, it may be accomplished in the form of a computer program (computer code) executed on a server, which is effectively then a programmed computer. Associated with this apparatus therefore is a computer readable medium which would store the relevant computer code. The same is true of the  FIG. 2  apparatus  50 . 
     In  FIG. 1 , apparatus  20  is part of an otherwise conventional DRM authentication process. The incoming data (e.g., a piece of content) which may already have been partly processed or may still be in original form is submitted as data in the upper left hand portion to a data storage element such as a register in memory  24 . This is then coupled to a partitioner  26  which partitions the data into blocks of length S. The blocks are then transmitted to an input block storage  38  which outputs the input blocks lb to a transformer element  40 . Element  40  carries out the transformations as explained above. 
     Transformer element  40  is driven by a transformation selector  30  which has the ability (determined by the system designer) to select at any one time which particular transformation of the defined family is to be used. For instance, the choice may be based on the current state of the host device (server.) Selector  30  is coupled to a transformation storage element  34  which stores the various transformations T i  in the family T, or at least the parameters to define each T i . The selected transformation T i  (or its parameters) is supplied to the transformer  40  which performs the actual transformation calculation and outputs the output blocks ob to an output data storage element  42 . Element  42  is in communication with the remainder of the authentication process, and ultimately the digest or HMAC associated with the content is transmitted to the user devices, for instance over the Internet. 
       FIG. 2  shows the complementary apparatus  50  at the user (recipient) device. Again only the relevant portions are shown and typically this would be part of a DRM system at the user device, in this case in the context of authentication. The content data transmitted from the host server of the apparatus of  FIG. 1  is received by recipient apparatus  50  in the upper portion of  FIG. 2  and is stored in the protected data storage (e.g., register)  52 . Next is partitioner element  54  which partitions the received content data into blocks each of length S, outputting lb blocks. These blocks are then stored in the lb block storage (e.g., register)  58 . These are then supplied one block at a time to the transformer element  60  which has been previously set to carry out the transformation of  FIG. 1 . Each transformation function is the same as the original, and used for determining a symmetric key. Transformer element  60  then outputs the retransformed (restored) ob blocks to an ob block storage (register)  64  and hence they are communicated to the remainder of the DRM process to be used conventionally for authentication of the content. 
     In addition to a method, the present disclosure contemplates the above disclosed associated apparatus, at both the transmitting and receiving devices (platforms). The method may be embodied in a computer program, and the associated apparatus may include a programmed computer or computing device, as well as a computer readable medium storing the code of the computer program. The computer program may be coded in any convenient computer language such as C++. 
     This disclosure is illustrative and not limiting; further modifications and improvements will be apparent to those skilled in the art in light of this disclosure and are intended to fall within the scope of the appended claims.