Abstract:
A digital content security system and method encrypts a key required for playback of digital content, fragments the encrypted key and embeds the fragments in portions of a payload; encrypts determined portions of frames of the digital content, and uses the decrypted key to decrypt the encrypted portions for playback in real-time; and requires an active authenticated session to access the encrypted key, decrypt it, access the encrypted portions and decrypt them.

Description:
PROVISIONAL APPLICATION  
       [0001]    This application claims priority to U.S. Provisional Application 60/399,846, filed Jul. 30, 2002, the entire contents of which are hereby incorporated by reference herein. 
     
    
     
       FIELD OF THE INVENTION  
         [0002]    This invention relates generally to data security, and more particularly to an end-to-end system and method for secure delivery and playback of multimedia data.  
         BACKGROUND  
         [0003]    Intellectual property rights management is critical to the successful deployment of Video on Demand (VOD) and Download and Store (D&amp;S) systems. Copyright owners demand that their content be distributed in a secure manner such that only authorized parties have access to the content, only on authorized equipment, typically only for an authorized time period (e.g., 1 viewing or X hours), and only for authorized viewing (i.e., not reproduction or distribution). Concomitantly, the security system should not compromise playback, such as by introducing material delays, create unreasonable complications for the end-user, or result in increased cost, such as by requiring new hardware. Achieving these objectives for VOD, D&amp;S and related systems requires encryption and authentication.  
         SUMMARY  
         [0004]    It is therefore an object of the present invention to provide a digital data security system that enables efficient encryption and decryption.  
           [0005]    It is another object of the present invention to provide a digital data security system that enables user authentication and playback equipment authentication.  
           [0006]    It is also another object of the invention to provide a digital data security system that is suitable for implementation with Video On Demand, Download and Store (video and/or music), Video Conferencing and  
           [0007]    Streaming Music Systems.  
           [0008]    It is yet another object of the invention to provide a digital data security system that encrypts a key required for playback, fragments the encrypted key and embeds the fragments in portions of the payload.  
           [0009]    It is a further object of the invention to provide a digital data security system that requires an online session using authenticated ports to decrypt and play downloaded data.  
           [0010]    To achieve these and other objects, an exemplary methodology is provided that encrypts a key required for playback of digital content, fragments the encrypted key and embeds the fragments in portions of a payload; encrypts determined portions of frames of the digital content, and uses the decrypted key to decrypt the encrypted portions for playback in real-time; and requires an active authenticated session to access the encrypted key, decrypt it, access the encrypted portions and decrypt them. Applying dynamic layers of authentication, key encryption and data encryption, the exemplary methodology achieves a high level of security. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0011]    The foregoing and other objects, features and advantages of the present invention will become better understood with reference to the following description and accompanying drawings, where:  
         [0012]    [0012]FIG. 1 conceptually depicts an exemplary sign-up process in accordance with a preferred implementation of the present invention;  
         [0013]    [0013]FIG. 2 conceptually depicts an exemplary player software download process in accordance with a preferred implementation of the present invention;  
         [0014]    [0014]FIG. 3 conceptually depicts a working session initiation process in accordance with a preferred implementation of the present invention;  
         [0015]    [0015]FIG. 4 conceptually depicts a movie database update process in accordance with a preferred implementation of the present invention;  
         [0016]    [0016]FIG. 5 conceptually depicts a transaction request process in accordance with a preferred implementation of the present invention;  
         [0017]    [0017]FIG. 6 conceptually depicts a key fragmentation process in accordance with a preferred implementation of the present invention;  
         [0018]    [0018]FIG. 7 conceptually depicts a playback authentication process in accordance with a preferred implementation of the present invention; and  
         [0019]    [0019]FIG. 8 conceptually depicts a decryption process in accordance with a preferred implementation of the present invention. 
     
    
     DETAILED DESCRIPTION  
       [0020]    A methodology in accordance with an exemplary embodiment of the present invention may include several processes (as referenced in the brief description of the drawings and the following detailed description) in combination to provide an end-to-end solution. Alternatively, a process (such as the encrypted key fragmentation and embedding process) may be used individually, apart from the other processes described below, and come within the scope of the present invention.  
         [0021]    An exemplary setup process entails establishing an account and obtaining necessary software, such as a player. To access a video distribution system in accordance with a preferred implementation of the present invention, a new user may visit a web site and sign-up for a new account. Referring to FIG. 1, the user may provide a name, address and other relevant information  110 . To establish the account, the user may be asked to create a user ID (Login) and password. When the user finishes creating the account, a unique private key  120  associated with the new user, the account key, may be stored on a database resident at a remote master server.  
         [0022]    Alternative methods for account setup include telephonic, with or without the assistance of a customer service representative, and conventional account establishment means known in the art. For example, an account may be established by dialing a number and entering data telephonically to a server having a telephony application program interface (TAPI), or by other data entry methods known in the art.  
         [0023]    In addition to setting-up an account, a new user preferably downloads and installs on her equipment, such as a PC (i.e., the client), certain software such as a video player software application (i.e., player software). The newly registered user may log into the web site  260  to download the player software. Upon logging in, the account key is retrieved from the remote master server  210 . The client installs the player software across the Internet  270  and  280  and the player software package is stamped with (i.e., associated with) a scrambled version of the account key.  
         [0024]    Alternatively, a copy of the player software may be recorded on a medium, such as a diskette, CD-ROM or hardware (e.g., firmware, a set-top box, or ROM) and provided to a user. The player software as provided on such a medium may either be pre-configured with a stamped scrambled version of the account key or require the user to download and install it. The player software may also be downloaded while the digital content is downloaded as an integral part of the digital content payload or as a separate payload sent before, during or after the digital content payload.  
         [0025]    The player software preferably incorporates security features to prevent tampering with its functionality. The player may be broken into components, and as the components are combined, a decryptor may check the integrity of each component by byte signature and 32 bit CRC checks. In addition, during playback, if any component fails, the decryptor will render no input or output pins, and will attempt to unload itself. This prevents the media stream from being decrypted by a tampered player.  
         [0026]    During use, the player software may send information to a server and receive information from the server to verify and authenticate information pertaining to the user, player software, equipment and/or session. For example, the player software may scramble and send to a local server a small portion of the user information, such as the User ID  250 . The server may unscramble the user information and use it to retrieve the account key from the remote master server  210  and copy the user account information to the local master  220  and slave  230  servers for caching. The slave server  230  may then send an AES encrypted authentication challenge  240  to the client, along with additional connection information. The client may deploy its locally stamped account key to decipher the authentication challenge and the connection information. The connection information may be used by the client to create a new private key, the connection key (connection information+user&#39;s private key [i.e., account key]), which may be used to encrypt computer-specific information along with the authentication response.  
         [0027]    The preferred Advanced Encryption Standard (AES) specifies a Federal Information Processing Standards-approved symmetric block cipher that can be used to encrypt and decrypt electronic data. AES is capable of using cryptographic keys of 128, 192 and 256 bits to encrypt and decrypt data in blocks of 128 bits. Those skilled in the art will appreciate that other encryption methodologies, whether proprietary or not and whether adopted as an industry or government standard or not, may be used in lieu of AES without departing from the scope of the present invention.  
         [0028]    The server may then decrypt the message and read the response. If the server can read the response, it may log the IP and hardware hash to the account and grant access by response with the final key used with AES encryption on the payload.  
         [0029]    In addition to performing authentication steps prior to use of the player software for downloading and playing content, the client (via the player software) may create a unique private working session key that may be unlocked using a hash comprised of computer specific information, connection information and the account key  330 ,  350 . Both the client and server know each of these locally. This working session key  340  may used for all future communications during the current active session, including user login. The user may be authenticated via her User ID and password  310 . The user&#39;s login password may be transmitted to the server encrypted using the working session key.  
         [0030]    The client may then request updates (e.g., an updated database of available movies) from the server and process them as well as commands to remove expired media and update the local databases  430 .  
         [0031]    The databases are preferably AES encrypted on the master server with a randomized master server key and then duplicated to the slave servers  410  and  420 . When the client requests the databases, it receives the encrypted database and the key for the database separately  440 . The database key may be encrypted with the working session key, and sent to the client to decrypt the database locally.  
         [0032]    A user&#39;s request to download or stream media  540  may be relayed from the web site server to the slave servers  510  and  520 . The slave servers may process the request by interfacing with credit card authorization systems and by checking any security policies  530 .  
         [0033]    If the delivery of the media (i.e., digital content) is authorized, the slave server may dynamically select a connection port for future communications and calculate a server port hash value  570 . The server may then transmit to the client connection information based on the client&#39;s computer specific information and server side port hash values  550 . The server preferably assigns ports dynamically, because standard static ports are much easier to trace. The client may then decipher the actual port number from the payload using its computer specific information  550 . A copy of the connection specific information can be stored in the account for the specific media file on the server.  
         [0034]    When a first packet is sent, preferably the server will wait a determined amount of time (e.g., a maximum of 2000 ms) for an acknowledgement from the client. If one is not received, then the server may issue a new session ID and instruct the client to renegotiate the port and packet again. This deters freezing the system (i.e., “ice capping”) and attempts to decipher the byte flow.  
         [0035]    The key for the actual media  620 ,  660  may be encrypted with the working key, scrambled in a determined fashion and then sent. A copy of the session ID is stored in the account for the media file on the server. The key may be broken up into fragments  630 ,  670 , which are preferably embedded and transferred in portions of the payload in a download and store implementation. The fragments may be of equal or unequal sizes. They may be embedded in the payload in order (least significant to most significant bit or vice versa) or out of order. The fragments may be separated according to a determined algorithm, which may embed each fragment at a location determined relative to a location for a preceding fragment (if any). The algorithm may be based upon formulae, packet information, session information, media data, client information, user information and/or any combination of the foregoing. The algorithm may be hard-coded into the player software, or variable, in whole or in part, periodically, as a rule defined by a server. If variable, the algorithm may change from time to time during a session, after each n th  session, after a random interval and/or upon management directive. If downloaded, the algorithm would preferably be provided during a secure authenticated session in an encrypted form, perhaps as part of the payload. In a streaming mode, the fragments may be embedded within buffered frames (e.g., approximately 90 frames for a 3 second buffer)  680 . These several variables (i.e., frames containing fragments, fragment size, fragment location, fragment order, and fragment encryption) substantially reduce the risk of successful hacking. Only by obtaining all frames containing all encrypted fragments, determining the location and size of each fragment, reconstructing the encrypted key based on a proper ordering of the fragments, and decrypting the reconstructed key, would security potentially be compromised.  
         [0036]    The client will receive the media stream, extract the fragments of the media key, segment by segment, from the payload, and either reconstruct the encrypted key and place it into an encrypted secure container  710  (e.g., an encrypted temporary file or sector) or place the fragments into the encrypted secure container  710 . The media key may remain in encrypted form (and possibly in a fragmented form) within the secure container.  
         [0037]    In a streaming mode (e.g., VOD), once the buffer is ready for playback, the media key may be deciphered in volatile memory (or in non-volatile memory) and playback begins  730 . The media key can be kept scrambled in memory except when it is actively being used by the “decryptor”. When not in active use, the media key may be rescrambled using a new value.  
         [0038]    In a download and store mode, upon user request for playback, the client may request authentication from the server  740 . If successful, the server will send the connection specific information (e.g., session ID) stored for that media file to the client  750  using AES encryption with the working session key  760 . The connection specific information is the only component that is not present in the encrypted secure container but which is necessary to unlock the media key. As a result, the hardware information from time of download to time of playback must stay the same.  
         [0039]    Decryption of the media file may be performed during playback. The process begins by querying attributes of each video and time frame to determine the type of decryption (if any) that needs to be applied  810 - 830 . If a frame is not encrypted, decryption is not performed  850 . The “decryption key” used for decryption of the actual media values in each block of data is extracted through several decryption iterations that start with decryption of the media key and other attributes of the media  840 .  
         [0040]    All server-side keys are preferably scrambled by algorithms that use 512-bit keys, and are securely stored at the video storage site. In addition, 128/192/256-bit AES encryption is applied to the video payload itself. The video payload decryption key, which may be dynamically created at the video server and fragmented and embedded throughout the actual video payload moments before downloading or streaming begins as described above, is preferably unique for each particular user session and media content.  
         [0041]    Initial encryption of the media content is performed during the encoding process. The encryption key is dependent on the media itself and the selection of media samples (e.g., frames or portions thereof) to be encrypted may be dictated by a determined cryptographic formula  840 . Several layers of encryption are applied as the encrypted media content is packaged for delivery to the user. These layers involve encryption of the decryption keys prior to transmission to the client and, of course, encryption of the video payload itself.  
         [0042]    In a preferred implementation, portions of determined frames are encrypted. The portions may be from one byte to an entire frame. Each frame may include from zero to a plurality of encrypted portions. The location of an encrypted portion within a frame may be determined according to an algorithm (i.e., a determined cryptographic formula). Such an algorithm may be based upon formulae, random data, packet information, session information, media data, client information, user information and/or a combination of the foregoing. The algorithm may be hard-coded into the player software, or downloaded (in an encrypted format), in whole or in part, periodically or with each session as a rule defined by the server. Only by determining which frames contain one or more encrypted portions, determining the number of encrypted portions in each such frame, determining the location and size of each encrypted portion within each such frame, and then decrypting the portions, would security potentially be compromised. Those skilled in the art will appreciate that the last step (i.e., decrypting the portions) will preferably require an active authenticated session and decryption of the reconstructed key as described above, thus combining additional layers of security.  
         [0043]    In the Download and Store and streaming modes, the system may require the client to be connected to the server throughout the entire playback (for example, the entire movie) for successful playback of the content resident on the client&#39;s disk (Download and Store mode) or being streamed and buffered (streaming mode). If the connection is lost, or deliberately broken, the player software preferably re-negotiates the session, re-authenticates and continues viewing. If re-authentication is not accomplished after a predetermined time, the player software preferably halts playback. Alternatively, or in addition to the foregoing, a presentation (temporal) stamp can be embedded in the cipher, thereby allowing viewing of downloaded video after an initial authentication, with or without the need to remain connected to the system throughout the length of the movie, for a limited time. Upon expiration of the time stamp (a given number of hours or days), video decryption and playback will cease.  
         [0044]    To protect content further, the system preferably decrypts content only for authorized playback. Storage of encrypted content may only be allowed in the Download and Store mode. Stored content may be deleted from the client during the next connection to the server by overwriting a zeroed file to the same location and then deleting the file. In the VOD Streaming mode, preferably no content is stored except for in the frame buffer. Even if encrypted content is somehow extracted from the client playback, unauthorized decryption may not be feasible because encryption is a dynamic process requiring cooperation between server and client.  
         [0045]    The player preferably decrypts the media (i.e., digital content), decompresses (i.e., decodes) it and passes it directly to a renderer  860 , which may send the media directly to the frame buffer, thereby deterring ‘frame sample’ ripping. This also allows for a high quality image by eliminating color translation.  
         [0046]    Those skilled in the art will appreciate that the exemplary methodology was designed to discourage attacks by sophisticated amateur hackers and to make it difficult and expensive for professional hackers to break the security of the system and extract a clean video payload. Concomitantly, the exemplary encryption methodology was designed to minimize the processing and latency overheads frequently associated with encryption technologies, making the system scalable and providing a pleasant user experience by eliminating unnecessary delays in the playback of the media content.  
         [0047]    While the invention has been described in terms of its preferred embodiments, those skilled in the art will recognize that the invention can be practiced with modifications within the spirit and scope of the foregoing detailed description. Such alternative embodiments and implementations are intended to come within the scope of the present invention.