Abstract:
A content protection system for securely delivering audio/video data from a content server to a content client through an unsecured channel is disclosed. For each session, the content protection system comprises two phases. The first phase is client-server mutual authentication and session key establishment. In this phase, the content server and the content client verify each other&#39;s legitimacy, and at the same time exchange information so that both server and client can calculate or derive the same session key. In the second phase, audio/video data is encrypted with the session key in the content server, and then decrypted with the session key in the content client. If a version of server or client is found to be compromised, its ID will be put into a blacklist.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    The present invention relates to content protection systems. More specifically, the present invention discloses a digital content protection system that allows audio and video data to be securely delivered from a content server to a content client. 
         [0003]    2. Description of the Prior Art 
         [0004]    As the internet continues increasing in robustness, a growing number of content providers are supplying multimedia to users. Users are able to view the multimedia in streaming format rather than downloading an entire file. However, this method of content delivery has several disadvantages or challenges. 
         [0005]    For one, the internet connection must be of suitable bandwidth to accommodate the data transfer. Insufficient bandwidth usually results in jerky video playback. 
         [0006]    Additionally, if a channel is unsecured, a hacker could intercept all communication between the content server and the content client. A re-play attack is where the hacker records all communicated data in one session, and then the hacker impersonates the content server and feeds the recorded data to a content client in another session. 
         [0007]    If a hacker successfully records the media content and is able to impersonate a content server, the content provider will lose potential revenue that would be normally generated by distributing the media content to a client. 
         [0008]    Furthermore, the media content may contain sensitive, classified information, private information, trade secrets, or content that is intended for viewing only by the intended client. Lack of implementing proper protection procedures could allow the media content to fall into inappropriate hands. 
         [0009]    Moreover, once the media content is out of the content provider&#39;s control, the media can easily be re-distributed. 
         [0010]    Therefore there is need for a system to protect multimedia content when multimedia data is delivered through an unsecured channel. 
       SUMMARY OF THE INVENTION 
       [0011]    To achieve these and other advantages and in order to overcome the disadvantages of the conventional method in accordance with the purpose of the invention as embodied and broadly described herein, the present invention provides a content protection system for securely delivering audio/video data from a content server to a content client through an unsecured channel. 
         [0012]    The content server and the content client can be either hardware or software modules. If the channel is unsecured, a hacker could intercept all communication between the content server and the content client. The system of the present invention not only stops the hacker from getting clear-text data, but also prevents a re-play attack. 
         [0013]    For each session, the content protection system of the present invention is composed of two phases. The first phase is client-server mutual authentication and session key establishment. In this phase, the content server and the content client verify each other&#39;s legitimacy, and at the same time exchange information so that both server and client can calculate/derive the same session key. In the second phase, audio/video data is encrypted with the session key in the content server, and then decrypted with the session key in the content client. 
         [0014]    The present invention employs symmetric ciphers as its components. An advantage of the content protection system is that well-known ciphers are used instead of designing a new one. For example, a 128 bit AES cipher can be used because its security is well trusted and it could be implemented in software with fast-computation and in hardware with low gate-count. Alternatively, the cipher could also be other block ciphers, such as DES, Blowfish, or RC4, etc. 
         [0015]    Additionally, if a version of server or client is found to be compromised, its ID will be put into a blacklist. Every server and client contains this blacklist, and this list is periodically updated. If a server finds a client&#39;s identification number is in the blacklist, it will terminate the session. If a client finds a server&#39;s identification number is in the blacklist, it will terminate the session. 
         [0016]    These and other objectives of the present invention will become obvious to those of ordinary skill in the art after reading the following detailed description of preferred embodiments. 
         [0017]    It is to be understood that both the foregoing general description and the following detailed description are exemplary, and are intended to provide further explanation of the invention as claimed. 
     
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0018]    The accompanying drawings are included to provide a further understanding of the invention, and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. In the drawings: 
           [0019]      FIG. 1A  is a diagram illustrating client and server communication flow according to an embodiment of the present invention; 
           [0020]      FIG. 1B  is a flowchart illustrating an authentication process according to an embodiment of the present invention; 
           [0021]      FIG. 1C  is a flowchart illustrating a session key establishment process according to an embodiment of the present invention; 
           [0022]      FIGS. 2A-2C  are flowcharts illustrating digital content encryption/decryption processes according to embodiments of the present invention; and 
           [0023]      FIG. 3  is a flowchart illustrating a revocation process according to an embodiment of the present invention. 
       
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0024]    Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the description to refer to the same or like parts. 
         [0025]    Refer to  FIG. 1A , which is a diagram illustrating client and server communication flow according to an embodiment of the present invention and to  FIG. 1B , which is a flowchart illustrating an authentication process according to an embodiment of the present invention. 
         [0026]    The first phase of the content protection system of the present invention comprises client-server mutual authentication and session key establishment. The challenge/response process as depicted allows the server  50  and the client  60  authenticate each other, and also establishes a session key. The symbols used in the process are first defined as follows:
       ∥ Concatenation   ⊕ XOR   R 1  A 128 bit random number generated by the server.   R 2  A 128 bit random number generated by the client.   K X1 , K X2  A pair of 128-bit secret keys that the client and the server will use to secure the data exchanged during mutual authentication and session key establishment. Both server and client have this pair of keys embedded inside.   ID S  A 128 bit identification number of the server. Server proposes this number to client, so that client knows which server it is dealing with. Each version of server has a unique ID. All instances of the same version share the same ID.   ID C  A 128 bit identification number of the client. Client proposes this number to server, so that server could know which secret keys should be used. Each version of client has a unique ID. All instances of the same version share the same ID.   E Kx1 ( ) AES encryption using the secret key K X1 .   E Kx2 ( ) AES encryption using the secret key K X2 .   E C ( ) AES encryption using the CommonKey. CommonKey key is a fixed 128 bit number that all versions of servers and clients know.   K S1  A 128 bit random number generated by server. It is used as part of the session key.   K S2  A 128 bit random number generated by client. It is used as part of the session key.   K S  The session key       
 
         [0040]    As shown in  FIG. 1A  and  FIG. 1B , steps of the authentication process  100  comprises:
       Step  105  Server  50  notifies client  60  to start the authentication process.   Step  110  Server  50  sends random number R 1  and E C (ID S  ⊕ R 1 ) to client  60 .   Step  112  Client  60  uses the CommonKey to decrypt E C (ID S  ⊕ R 1 ) into (ID S  ⊕ R 1 ), and then extracts ID S .   Step  113  Client  60  uses ID S  to look up the secret key pair K X1  and K X2      Step  115  Client  60  generates random numbers R 2  and K S2 . Client  60  uses AES encryption to generate the sequence R 2  ∥ E C (ID C  ⊕ R 2 ) ∥ E Kx2 (R 1  ∥ K S2 ), and then sends it to Server  50 .   Step  120  Server  50  uses the CommonKey to decrypt E C (ID C  ⊕ R 2 ) into (ID C  ⊕ R 2 ), and then extracts ID C .   Step  125  Server  50  uses ID C  to look up the secret key pair K X1  and K X2      Step  130  Server  50  uses K X2  to decrypt E Kx2 (R 1  ∥ K S2 ) into (R 1 ′ ∥ K S2 ′).   Step  135  If R 1 ′ is not equal to R 1 , authentication failed and server  50  terminates the session.   Step  140  Server  50  generates random number K S1 .   Step  145  Server  50  uses AES encryption to encrypt (R 2  ∥ K S1 ) into E Kx1 (R 2  ∥ K S1 ), and then sends it to Client  60 .   Step  150  Client  60  uses secret key K X1  to decrypt E Kx1 (R 2  ∥ K S1 ) into (R 2 ′ ∥ K S1 ′).   Step  160  If R 2 ′ is not equal to R 2 , authentication failed and client  60  terminates the session.       
 
         [0054]    Refer to  FIG. 1C , which is a flowchart illustrating a session key establishment process  160  according to an embodiment of the present invention. After the process illustrated in  FIG. 1B  is done and the session wasn&#39;t terminated by server or client, mutual authentication has succeeded. In order to establish the session key, the server and client perform the following steps:
       Step  165  Server calculates the session key as K S =K S1  ⊕ K S2 ′.   Step  170  Client calculates the session key as K S ′=K S1 ′ ⊕ K S2 . K S ′ should be identical to K S .       
 
         [0057]    Alternatively, server can calculate the session key as K S =E Ks1 (K S2 ′), and client can calculate the session key as K S ′=E Ks1′ (K S2 ). K S ′ should be identical to K S . 
         [0058]    Refer to  FIG. 2A , which is a flowchart illustrating a digital content encryption/decryption process  200  according to an embodiment of the present invention. 
         [0059]    After the authentication  100  and session key establishment processes  160  illustrated in  FIGS. 1B and 1C  have successfully completed, the transmission of audio/video data can begin. The encryption/decryption process  200  comprises the following steps:
       Step  205  Server encrypts audio/video data using the session key K S  and 128 bit AES cipher.   Step  210  Client decrypts the audio/video data using session key K S ′.       
 
         [0062]    For high quality video, for example HDTV, the resolution can be very high, such as 1920×1080×30 fps. In this case, the uncompressed video stream could be very high in bitrate, around 120 MByte/sec. Thus, the payload encryption method described in FIG.  2 A would require both server and client to have very high computing power. The fasted CPUs may not be fast enough, and GPUs on graphic cards are likely not fast enough to decrypt 120 Mbytes of data each second using AES decryption. 
         [0063]    Therefore in an embodiment of the present invention an alternative method is utilized to encrypt the video payload. For each video frame, a 128 bit number K Fi  is generated using the following method, and K Fi  is used as the frame key to encrypt the i th  video frame. 
         [0000]        K   F     1     =E   Ks (1), for  i= 1 
         [0000]        K   F     i     =K   F     i−1      ⊕ E   Ks ( K   F     i−1   ), for  i&gt; 1 
         [0064]    The encryption/decryption method  220  illustrated in  FIG. 2B  comprises the following steps:
       Step  225  Determine i.   Step  230  For each i value, if i=1, server encrypts the whole video frame using K F1 .   Step  235  If i&gt;1, server encrypts the whole video frame using K Fi .       
 
         [0068]    In this embodiment the method to encrypt a video frame using K Fi  comprises using RC4 stream cipher to encrypt the whole video frame. RC4 is several times faster than AES. The benefit of this method is that RC4 is a well-established cipher that people trust. 
         [0069]    Alternatively in cases where this method using RC4 is not fast enough, the present invention utilizes another method to encrypt a video frame. 
         [0070]    Refer to  FIG. 2C , which is a flowchart illustrating a digital content encryption/decryption process  240  according to an embodiment of the present invention. In this method the video frame is divided into macro-blocks, with each macro-block containing 16×16 pixels. In this embodiment the following symbols are defined as: 
         [0071]    M i  The i th  macro-block in the video frame. 
         [0072]    W The width of the video frame in terms of pixels. 
         [0073]    H The height of the video frame in terms of pixels. 
         [0074]    P A prime number which is also relatively prime to (W/16). 
         [0075]    S(M i ) Scramble M i  using a very light-weight algorithm, for example 3 CPUcycle/byte. 
         [0076]    The encryption method  240  comprises the following steps: 
         [0077]    Step  245  Determine i. 
         [0078]    Step  250  For each i value, if i (mod P)=1, encrypt M i  using RC4. 
         [0079]    Step  255  If i (mod P)≠1, encrypt M i  as: 
         [0000]        S ( M   └(i−1)/P┘×P+1 ) ⊕  M   i    
         [0080]    This method is approximately P times faster than encrypting the whole video with RC4. 
         [0081]    Refer to  FIG. 3 , which is a flowchart illustrating a revocation process  300  according to an embodiment of the present invention. 
         [0082]    If a version of server or client is found to be compromised, its ID will be put into a blacklist. Every server and client contains this blacklist, and this list is updated periodically. The revocation process  300  illustrated in  FIG. 3  comprises the following steps: 
         [0083]    Step  305  Client receives ID S  from server. 
         [0084]    Step  310  Client determines whether the ID S  is in the blacklist. 
         [0085]    Step  315  If the ID S  is in the black list, client terminates the session. 
         [0086]    Step  320  Server receives ID C  from client. 
         [0087]    Step  325  Server determines whether the ID C  is in the blacklist. 
         [0088]    Step  330  If the ID C  is in the black list, server terminates the session. 
         [0089]    The client checks the blacklist before it sends data to server in Step  115  of  FIG. 1B . The server checks the blacklist before it sends data to the client in Step  140  of  FIG. 1B . 
         [0090]    The present invention employs symmetric ciphers as its components. It should be noted that the method of the present invention can utilize various ciphers. For example, a 128 bit AES cipher can be used because its security is well trusted and it could be implemented in software with fast-computation and in hardware with low gate-count. Alternatively, the cipher could also be other ciphers, such as DES, Blowfish, or RC4, etc. 
         [0091]    It will be apparent to those skilled in the art that various modifications and variations can be made to the present invention without departing from the scope or spirit of the invention. In view of the foregoing, it is intended that the present invention cover modifications and variations of this invention provided they fall within the scope of the invention and its equivalent.