Patent Abstract:
A method for protecting a software video player having Advanced Access Content System (AACS) includes reading segments of an encrypted first key from noncontiguous regions of memory, assembling the segments to form the encrypted first key, decrypting the encrypted first key with a second key to form a first key, extracting AACS key data from a pack file, decrypting the AACS key data to retrieve AACS Device Keys, generating an AACS Title Key using the AACS Device Key, clearing the AACS Device Keys and the first key from memory after the AACS Title Key is generated, decrying encrypted AACS content with the AACS Title Key to form AACS content, and displaying the AACS content.

Full Description:
FIELD OF INVENTION 
       [0001]    This invention relates to apparatus and method for protecting the Advanced Access Content System (AACS) in software video players. 
       DESCRIPTION OF RELATED ART 
       [0002]    The Advanced Access Content System (AACS) is a standard for content distribution and digital rights management that is intended to restrict access to and copying of High Density (HD) and Blue-ray Disk (BD) media. It was developed by AACS Licensing Administrator, LLC (AACS LA), a consortium that includes Disney, Intel, Microsoft, Matsushita (Panasonic), Warner Brothers, IBM, Toshiba, and Sony. 
         [0003]      FIG. 1  presents a simplified view of encryption and decryption processes for pre-recorded video content provided by AACS. An owner of content that is to be protected provides the content in the form of one or more Titles to a licensed replicator. The licensed replicator selects a secret, random Title Key (Kt) for encrypting each Title. The licensed replicator also assigns a random Volume ID to the protected Title or a set of protected Titles to safeguard against “bit-by-bit copying” of protected content. The Volume ID is stored on a prerecorded medium in a manner that cannot be duplicated by consumer recorders. 
         [0004]    For each protected Title or a set of protected Titles to be included together on the pre-recorded medium, the AACS LA provides to the licensed replicator a Media Key Block (MKB), a Sequence Key Block, and a secret Media Key (Km). The MKB will enable all compliant devices, each using their set of secret Device Keys and Sequence Keys, to calculate the same or variants of the Media Key. If a set of Device Keys is compromised in a way that threatens the integrity of the system, an updated MKB can be released that will cause a device with the compromised set of Device Keys to calculate a different Media Key than the remaining compliant devices. In this way, the compromised Device Keys are “revoked” by the new MKB. 
         [0005]    For each protected Title, the licensed replicator calculates a cryptographic hash of the Media Key and the Volume ID, and uses the result to encrypt the Title&#39;s Title Key. The encrypted Title Key and the MKB are stored on the pre-recorded medium. 
         [0006]    The AACS LA provides a set of 253 secret Device Keys to the licensed manufacturer for inclusion into each compliant device or application produced. Device Key sets may either be unique per licensed product, or used commonly by multiple products. 
         [0007]    The licensed product reads the MKB from the pre-recorded medium, and uses its Device Keys to process the MKB and thereby calculate the Media Key. If the given set of Device Keys has not been revoked, then the calculated Media Key will be the same Media Key that was used by the licensed replicator as described above. 
         [0008]    For each protected Title the licensed product then calculates a cryptographic hash of the calculated Media Key and the Volume ID, and uses the result to decrypt the Title&#39;s encrypted Title Key. The result is then used to decrypt the Title. 
         [0009]    Playback of AACS content is only performed using the Title Keys and Volume ID which are read from the media. Except otherwise provided by the AACS specifications, the values used to enable playback of AACS content (e.g. Title Keys and Volume ID) shall be discarded upon removal of the instance of media from which they were retrieved. Any derived or intermediate cryptographic values shall also be discarded. 
         [0010]      FIG. 2  illustrates a conventional BD software video player  200  for AACS content. Software video player  200  is typically executed by a processor in a computer or in an appliance from codes and data loaded into volatile memory. Software video player  200  includes a player engine  201  with an AACS engine  202  and AACS keys  203  acquired from AACS LA. AACS keys  203  include a Host Certificate, a set of Device Keys, and a set of Sequence Keys. Using AACS keys  203 , AACS engine  202  decrypts data from an encrypted data source  204 . Depending on the user input, a BDMV (Blu-ray Disk Movie) engine  206  in player engine  201  instructs AACS engine  202  to access the appropriate files on encrypted data source  204 , receives the file from AACS engine  302 , and forwards the appropriate data to codec engine  208  in player engine  201 . Specifically, BDMV engine  206  splits the file that contains both audio and video data (and other data stream such as subtitles) and sends the appropriate data to a video codec and an audio codec (and other modules) in codec engine  208 . BDMV engine  206  also controls the synchronization between the video and audio from the video and the audio codecs. Codec engine  208  decodes the data and presents the content for display. Software video player  200  may include an application layer  207  that generates the user interface for controlling player engine  201 . Application layer  207  receives user controls and notifies BDMV engine  206  to respond to the user controls, such as playing a title. Application layer  207  also receives message from BDMV engine  206  to display to the user. 
         [0011]    Hackers have found various AACS keys by using debuggers to inspect the memory space of running HD-DVD and BD software video players. Thus, what are needed are method and apparatus for safeguarding the AACS content in HD-DVD and BD software video players. 
       SUMMARY 
       [0012]    In embodiments of the invention, methods are provided to protect AACS Device Keys in a software video player and to encrypt data transfers between modules of the player. 
         [0013]    In one embodiment, AACS Device Keys and their renewal information are packed into a file and then encrypted. When the software video player starts, the encrypted file is read into memory and decrypted. If the Device Keys have expired, the software video player will prompt the user to renew the Device Keys. Otherwise the software video player uses the Device Keys to calculate AACS Title Keys for decoding encrypted content. Afterwards, the software video player clears the memory of keys by filling it with random numbers. 
         [0014]    In one embodiment, to prevent static analysis, the Title Keys are encrypted with a random number and they are decrypted only when they are used. Afterwards use the Title Keys are encrypted immediately with a new random number. In addition, junk codes are inserted into essential places of the binary machine code of the software video player. Furthermore, the binary machine code self-decrypts dynamically only at runtime. 
         [0015]    In one embodiment, to prevent dynamic debugging, a monitoring mechanism in the system service is provided to detect debugging tools and determine whether or not the software video player is under conditions that indicate the player is being debugged. 
         [0016]    In one embodiment, authentication is used between certain modules of the player and encryption is used in data transfer between certain modules of the player. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0017]      FIG. 1  illustrates a simplified view of the AACS system. 
           [0018]      FIG. 2  illustrates a conventional software video player implemented with AACS. 
           [0019]      FIG. 3  illustrates a software video player implemented with additional safeguards for the AACS system in one embodiment of the invention. 
           [0020]      FIG. 4  illustrates an encrypted pack file format of AACS key data in one embodiment of the invention. 
           [0021]      FIG. 5  is a flowchart of a method for an AACS key manager in the software video player of  FIG. 3  in one embodiment of the invention. 
           [0022]      FIG. 6  illustrates the use of junk code in the source code in one embodiment of the invention. 
           [0023]      FIG. 7  illustrates authentication and encrypted data transfer between modules in one embodiment of the invention. 
           [0024]      FIG. 8  illustrates authentication between modules in one embodiment of the invention. 
           [0025]      FIG. 9  is a flowchart of a data encryption process between modules in one embodiment of the invention. 
           [0026]      FIG. 10  is a flowchart of a debugging monitoring process in one embodiment of the invention. 
       
    
    
       [0027]    Use of the same reference numbers in different figures indicates similar or identical elements. 
       DETAILED DESCRIPTION OF THE INVENTION 
       [0028]    Conventional software video player  200  of  FIG. 2  has certain disadvantages against hacking. First, AACS keys  203  are normally encoded into individual binary files for carrying out renewal. These binary files can be detected and analyzed to determine AACS keys  203 . Second, AACS keys  203  are not encrypted so they can be obtained by comparative analysis through memory dump. Even if they were encrypted, a hacker can use a debugging tool to find AACS keys  203  and use other tools to decrypt them. Third, when the modules of software video player  200  are implemented as filters with Microsoft DirectShow software development kit (SDK), data transfers between the modules are not protected. 
         [0029]    In embodiments of the invention, software video player is provided with (1) encryption of the AACS keys, (2) countermeasures against static analysis, (3) countermeasures against debugging tools, (4) authentication between modules of the player, and (5) encryption of data transfer between modules of the player. 
         [0030]      FIG. 3  illustrates a software video player  300  in one embodiment of the invention. To overcome the shortcomings of the conventional video player, software video player  300  includes the five features described above to strengthen the protection provided by the AACS. 
         [0031]    Software video player  300  is typically executed by a processor in a computer or in an appliance from codes and data loaded in volatile memory. Software video player  300  includes a player engine  301  with an AACS engine  302 . AACS engine  302  has hacking countermeasures so it does not directly access AACS keys. Instead, AACS engine  302  requests the AACS keys from an AACS key manager  304  only when the AACS keys are needed. In response, AACS key manager  304  decrypts an AACS key file  306  and provides the AACS keys to AACS engine  302 . 
         [0032]      FIG. 4  illustrates the format of AACS key file  306 . AACS key file  306  includes AACS key data  402 , a pack file header  404 , and an encryption header  406 . AACS key data  402  includes a Host Certificate, a set of Device Keys, and a set of Sequence Keys provided by AACS LA. Pack file header  404  includes the version of the pack file tool, the names of the source files, the creation date of the pack file, and the expiration date of AACS keys provided by AACS LA. Encryption header  406  includes information about the pack file itself, such as file size, the data offset, and so on. 
         [0033]    The contents of AACS key file  306  is packed and then encrypted by a Pack Tool using a random key  307  ( FIG. 3 ). The pack tool can use an encryption algorithm, such as AES. AACS key manager  304  manages random key  307  for AACS key file  306 , uses random key  307  to decrypt AACS key file  306 , retrieves AACS key data  402  from decrypted AACS key file  306 , and provides AACS key data  402  to AACS engine  302 . More importantly, AACS key manager  304  prevents hackers from finding AACS key data  402  through a memory dump. Using a memory dump, a hacker takes several static images of memory of an algorithm under different states and then finds the sensitive information by comparing the static images. To prevent such a memory dump, AACS key manager  304  uses several methods including (1) encrypting random key  307  in the memory with a temporary random key that changes frequently, (2) separating the encrypted random key  307  into several segment stored in noncontiguous memory, (3) creating the necessary AACS keys only when they are used, and (4) clearing the memory by filling the memory with random data after using the AACS keys. 
         [0034]      FIG. 5  is a flowchart of a method  500  performed by AACS key manager  304  in one embodiment of the invention. 
         [0035]    In step  504 , AACS key manager  304  encrypts or masks random key  307  with a temporary random key to prevent random key  307  from appearing directly in the memory during long playbacks. In one embodiment, AACS key manager  304  encrypts random key  307  by XORing it with the temporary random key. AACS key manager  304  creates a new temporary random key each time software video player  300  is started. Step  504  is followed by step  506 . 
         [0036]    In step  506 , AACS key manager  304  divides the encrypted random key  307  into multiple segments and stores them in noncontiguous memory regions. For example, AACS key manager  304  allocates different buffers through the operating system to store the segments. This again prevents random key  307  from appearing directly in the memory. Step  506  is followed by step  508 . 
         [0037]    In step  508 , AACS key manager  304  determines if AACS engine  302  is requesting AACS key data  402 . If so, then step  508  is followed by step  510 . Otherwise step  508  loops until AACS engine  302  requests AACS key data  402 . 
         [0038]    In step  510 , AACS key manager  304  assembles the segments of the key  307  and decrypts encrypted random key  307  with the temporary random key. 
         [0039]    In step  512 , AACS key manager  304  decrypts AACS key file  306  with random key  307 . Step  512  is followed by step  514 . In one embodiment, AACS key manager  304  reads the pack file header  404  to make sure the AACS keys have not expired. If the AACS keys have expired, AACS key manager  304  will prompt for the newest AACS keys. The newest AACS keys may be downloaded through the Internet or read from a disc. 
         [0040]    In step  514 , AACS key manager  304  retrieves AACS key data  402  from the decrypted AACS key file  306 . Step  514  is followed by step  516 . 
         [0041]    In step  516 , AACS key manager  304  provides AACS key data  402  to AACS engine  302 . In response, AACS engine  302  uses the Host Certificate to authenticate the optical drive, and the Device Keys and the Sequence Keys to calculate Title Key(s). As only the Title Key(s) are used for decrypting the media when the player is running, AACS key data  402  and random key  307  can be deleted after the Title Key(s) are determined. Step  516  is followed by step  518 . 
         [0042]    In step  518 , AACS key manager  304  clears AACS key data  402  from the memory by filling their memory locations with random numbers. Step  518  is followed by step  520 . 
         [0043]    In step  520 , AACS key manager  304  clears random key  307  from the memory by filling its memory location with random numbers. 
         [0044]    Referring back to  FIG. 3 , AACS engine  302  also includes junk code as a countermeasure against static analysis. Specifically the junk code is inserted into the source code of AACS engine  302  and then compiled into binary machine code. The strategic placement of the junk code in critical character strings and function transfers in the compiled binary machine code, such as those for the AES, makes them more difficult to decipher.  FIG. 6  illustrates assembly code  603  disassembled by a disassembler program (e.g., W32Dasm) from the binary machine code compiled from source code  601 .  FIG. 6  also illustrates an assembly code  604  disassembled from the binary machine code compiled from code  601  after junk code  602  is inserted. As  FIG. 6  shows, the disassembled code is changed by the junk code and is very difficult to decipher. 
         [0045]    AACS engine  302  further uses self-extraction as a countermeasure against static analysis. The binary code of AACS engine  302  is compressed and encrypted into a file by a development tool before release, and the file self-extracts dynamically at runtime. The binary code of AACS engine  302  can be encrypted by XORing the code with a predefined random number. 
         [0046]    Referring back to  FIG. 3 , a BDMV engine  308  in player engine  301  instructs AACS engine  302  to access the appropriate data on encrypted data source  204 , receives the data from AACS engine  302 , and forwards the data to a codec engine  312  in player engine  201 . In one embodiment of the invention, the modules of software video player  300  are implemented as filters with Microsoft DirectShow SDK. In one embodiment, AACS engine  302  and BDMV engine  308  are implemented in a single filter. 
         [0047]    Conventionally filters do not authenticate each other before data transfer and data transfer between filters are not protected. This provides opportunities for a hacker to exploit the filters if the hacker forges an empty filter that accepts decrypted data and dumps the data to a file. Therefore, software video player  300  is provided with authentication between certain modules and data encryption in the data transfer between certain modules in one embodiment of the invention. As illustrated in  FIGS. 3 and 7 , authentication is provided between BDMV engine  308  and application layer  310 , and between BDMV engine  308  and codec engine  312 . Furthermore, data encryption is provided to data transfer between BDMV engine  308  and codec engine  312 . 
         [0048]      FIG. 8  illustrates an authentication process  800  between a module that initiates the authentication (hereafter “initiator”) and a module that is the target of the authentication (hereafter “target”) in one embodiment of the invention. For example, BDMV engine  308  can be the initiator and one of application layer  310  and codec engine  312  can be the target. Authentication is performed each time the modules connect. 
         [0049]    In step  802 , the initiator sets an authentication flag for the target to FALSE, which indicates that the target has not been authenticated. Step  802  is followed by step  804 . 
         [0050]    In step  804 , the initiator generates a random number (e.g., a 16 byte). Step  804  is followed by step  806 . 
         [0051]    In step  806 , the initiator sends the random number to the target. Step  806  is followed by step  808 . 
         [0052]    In step  808 , the target encrypts the random number with its copy of a predefined key. Both the initiator and the target have the predefined key in their source codes. Step  808  is followed by step  810 . 
         [0053]    In step  810 , the target sends the encrypted random number to the initiator. Step  810  is followed by step  812 . 
         [0054]    In step  812 , the initiator verifies the encrypted random number by decrypting it with its copy of the predefined key. If the decrypted result matches the random number the initiator sent to the target, then the target is authenticated. Step  812  is followed by step  814 . 
         [0055]    In step  814 , the initiator sets the authentication flag to TRUE if the decrypted result matches the random number sent to the target. Otherwise the initiator leaves the authentication flag as FALSE. 
         [0056]      FIG. 9  is a flowchart of a method  900  for BDMV engine  308  to forward data to codec engine  312  in an encrypted data transfer in one embodiment of the invention. 
         [0057]    In step  902 , BDMV engine  308  determines if the authentication flag for codec engine  306  is TRUE. If so, codec engine  312  has been previously authenticated in process  800  ( FIG. 8 ) and step  902  is followed by step  904 . Otherwise step  902  is followed by step  916 , which ends method  900 . 
         [0058]    In step  904 , BDMV engine  308  creates a random number (e.g., 16 byte) as a key. Step  904  is followed by step  906 . 
         [0059]    In step  906 , BDMV engine  308  determines if a certain amount of time has passed since the key was created so it is time for generate a new key. If so, then step  906  is followed by step  908 . Otherwise step  906  is followed by step  910 . 
         [0060]    In step  908 , BDMV engine  308  generates a new random number as a key. Step  908  is followed by step  910 . 
         [0061]    In step  910 , BDMV engine  308  sends the key to codec engine  312  by a function call. Step  910  is followed by step  912 . 
         [0062]    In step  912 , BDMV engine  308  encrypts a stream of data with the key. In one embodiment, BDMV engine encrypts the data by XORing them with the key. Step  912  is followed by step  914 . 
         [0063]    In step  914 , BDMV engine  308  sends the encrypted data to codec engine  312 . In response, codec engine  312  uses the key received in step  910  to decrypt the data and otherwise process the data for display. Step  914  is followed by step  916 , which ends method  900 . 
         [0064]    Referring back to  FIG. 3 , software video player  300  includes a monitor process  314  in one embodiment of the invention. Monitor process  314  is a system service that starts running when the operating system is booted. If monitor process  314  detects whether software video player  300  is running a fixed time period after the software video player is started. If so, monitor process  314  starts an anti-debugging process. 
         [0065]      FIG. 10  is a flowchart of a method  1000  for monitor process  314  in one embodiment of the invention. 
         [0066]    In step  1002 , monitor process  314  determines if software video player  300  is running after the software video player was started. If so, then step  1002  is followed by step  1004 . Otherwise step  1002  is followed by step  1008 . 
         [0067]    In step  1004 , monitor process  314  determines if a debugging tool is running. This function is represented by reference numeral  316  ( FIG. 3 ) in monitor process  314 . Monitor process  314  has means to detect common debugging tools that are specific to each tool. If monitor process  314  detects a debugging tool, then step  1004  is followed by step  1010 . Otherwise step  1004  is followed by step  1006 . 
         [0068]    In one embodiment for the Win32 system, a check server is provided to prevent debugging. In the Win32 system, there is a thread information block (TIB) for each running thread. The check server checks TIB for flags that identify running threads of debugging tools in protection ring  3  (applications), such as Microsoft Visual Studio and OllyDbg. The check server also detects some debugging tools that run in protection ring  0  (kernel) by their driver names, file names, and sever names. For example, the check server attempts to create the same object handles with the same driver, file, and server names as the debugging tools. If the creation fails, then the debugging tools are present. When there is debugging tool attacking software video player  200 , the check server closes the player to prevent it from been hacked. 
         [0069]    In addition to the check server, a start server is provided to protect the check server from being attacked. The start server double checks the check server and the player are running without being debugged. Specifically, the start server determines whether or not the check server exists. Since the check server is a program of the Windows operating system, the start server looks for the processes of the check server using the Windows API. If the start server cannot find the processes of the check server, it restarts the check server again to protect the player. 
         [0070]    In step  1006 , monitor process  314  determines if software video player  300  is under conditions that indicate software video player  300  is being debugged. This function is represented by reference numeral  318  ( FIG. 3 ) in monitor process  314 . On Microsoft Windows platforms, an application is generally a child process of Windows Explorer. Thus, monitor process  314  determines if the parent process of software video player  300  is Windows Explorer. If not, then monitor process  314  assumes software video player  300  is being debugged and step  1006  is followed by step  1010 . Otherwise step  1006  is followed by step  1008 . 
         [0071]    In step  1008 , monitor process  314  waits for a timeout and then returns to step  1002  to again loop through method  1000 . 
         [0072]    In step  1010 , monitor process  314  applies debugging countermeasures. This function is represented by reference numeral  320  ( FIG. 3 ) in monitor process  314 . Debugging countermeasures include forcibly terminating software video player  300  and writing random data into process memory of player  300 . 
         [0073]    To thwart any attempt to disable monitor process  314 , application layer  310  and BDMV engine  308  both periodically detect monitor process  314  after software video player  300  is started. If either application layer  310  or BDMV engine  308  cannot detect monitor process  314 , it can forcibly terminate player  300  as a precaution against debugging. 
         [0074]    Various other adaptations and combinations of features of the embodiments disclosed are within the scope of the invention. Numerous embodiments are encompassed by the following claims.

Technology Classification (CPC): 7