Read/write media key block

[0001] This invention generally relates to the management of cryptographic keys for controlling access to protected content, particularly for recordable media.

[0002] The following patent applications and issued patents are hereby incorporated in their entirety by reference:

• • [0003] U.S. Pat. No. 5,081,677 issued Jan. 14, 1992, “Cryptographic Key Version Control Facility”.
  • [0004] U.S. Pat. No. 5,177,791 issued Jan. 5, 1993, “Secure Translation of Usage-Control Values for Cryptographic Keys”.
  • [0005] U.S. Pat. No. 5,412,723 issued May 2, 1995, “Mechanism for Keeping a Key Secret from Mobile Eavesdroppers”.
  • [0006] U.S. Pat. No. 6,118,873 issued Sep. 12, 2000, “System for Encrypting Broadcast Programs in the Presence of Compromised Receiver Devices”.
  • [0007] U.S. Pat. No. 6,748,539B1 issued Jun. 8, 2004, “System and Method for Securely Checking In and Checking Out Digitized Content”.
  • [0008] U.S. Ser. No. 09/575,740 filed May 22, 2000, “Coincidence-Free Media Key Block for Content Protection for Recordable Media”.

[0009] The advantages of digitized video and music are numerous, but one significant drawback is that being digitized, the content is relatively easy to copy perfectly, without authorization by the copyright owner. Pirating of content currently costs content providers billions of dollars each year. Therefore, numerous schemes have been developed to address this problem, but not all are practical given the large number of content instances and devices that handle content.

[0010] U.S. Pat. No. 6,118,873 provides an encryption system for the secure broadcasting of programs, including updates to authorized in-home digital video devices. That patent discloses a system for encrypting broadcast music, videos, and other content such that only authorized player-recorders can play and/or copy the content and only in accordance with rules established by the vendor of the content. Authorized players or recorders are issued software-implemented device keys from a matrix of device keys termed a media key block (MKB). The keys can be issued simultaneously with each other or over time, but in any event, no player-recorder is supposed to have more than one device key per column of the matrix. Although two devices might share the same key from the same column, the chances that any two devices share exactly the same set of keys from all the columns of the matrix are very small when keys are randomly assigned. The keys are used to decrypt content. Devices may be ‘revoked’ by encrypting future protected content in various ways such that particular selected devices cannot decrypt it properly.

[0011] In the case of recordable media, content protection is conventionally based on having a media key block on each media instance (in this application, the term “media” may refer to a particular data storage item or a plurality of such data storage items). This MKB allows compliant devices to calculate a proper media key, while preventing circumvention devices from doing the same thing. Heretofore, it has been important that the MKB be read-only, even though the rest of the medium is, of course, read/write, i.e. recordable. The MKB needs to be read-only because of the following so-called “down-level media” attack: if the MKB were read/write, an attacker could write an old broken MKB on the medium, and then ask a compliant device to encrypt and record a piece of content of interest to the attacker. Since the MKB is broken, the attacker knows the media key and can decrypt this content. The attacker thus gets the protected content in the clear, effectively defeating the goal of the content protection scheme.

[0012] However, having a read-only area on read/write media is often problematic. For example, in DVD-RAM, DVD-R, and DVD-R/W media, the MKB is pre-embossed on the lead-in area, a part of the disc not written into by recorders. The lead-in area has a limited capacity. Therefore, this approach inherently limits the size of the MKB, thereby restricting the number of circumvention devices that can be revoked. In the case of DVD+R and DVD+R/W media, the lead-in area is read/write. The approach used in that technology is to write only a digest of the MKB into the “burst cut area” (BCA), a very limited read-only area near the hub of the disc, during manufacture. Writing into the BCA adds another $0.05 to the cost of each disc, unfortunately.

[0013] A potentially more serious problem is that these approaches require the disc replicator to be involved in the process. Not all disc replicators wish to become licensees of the given content protection scheme, so to date each type of media has two versions: one with MKBs, and one without. Since only the MKB-containing media can be used to record protected content, there is substantial potential for consumer confusion. Furthermore, the disc replicators have to be constrained by license not to put too many discs out with the same MKB. If they did, the media key of that MKB could become an important global secret, the compromise of which could do serious damage to the content protection scheme. But there is a cost/security tradeoff involved, because the cost of replication is strongly dependent on the number of identical replicas that can be made. To date, that tradeoff has been made entirely to favor low cost: the replicators are allowed to use a single MKB a million times.

[0014] It is accordingly an object of this invention to provide a read-only MKB stored in each recorder device, instead of having read-only MKBs on blank media from disc replicators. The recorder device selectively writes protected digital content onto a recording medium according to the age of the stored MKB and any MKB that may be present in the recording medium. If there is no MKB in the medium, the recorder writes its stored MKB into the medium and then proceeds to write the protected content. If the MKB in the medium is older than the stored MKB, then the recorder writes the stored MKB into the medium and then re-encrypts the protected content and then writes it, eliminating the possibility that a broken older MKB can be used for piracy. If the MKB in the medium is newer than the stored MKB, then the recorder uses the newer MKB for writing protected content, but can optionally update its stored MKB with the newer MKB, eliminating the possibility that a broken older stored MKB can be used for piracy. Any recordable medium having a unique media ID or serial number can be employed by the system to store protected content. Costly modifications to media during manufacture can be avoided, and limitations to the size of MKBs are effectively eliminated.

[0016] In an exemplary embodiment, the present invention eliminates the difficulties described above by having a read-only MKB stored in each recorder device, instead of having read-only MKBs on blank media from disc replicators. The recorder can selectively write the stored MKB onto the media. There are several schemes known in the art for efficiently enabling a device to cryptographically determine which of two keys is the more recent, so the invention capitalizes on these schemes to help solve the problems with the conventional approaches described above. See for example U.S. Pat. Nos. 5,081,677 and 5,412,723, which describe the use of version numbers for cryptographic keys that are periodically “refreshed” for enhanced security. Note however that the invention is not limited to any specific scheme for determining the relative age of keys or MKBs. Therefore, referring now to FIG. 1 and according to the present invention, when a recorder is asked to record a piece of protected content, the content protection logic followed in the recorder is as follows:

• [0017] 1. If the media has no MKB, as determined in step 100, then in step 102 the recorder first writes its own MKB into the media before writing the content protected by that MKB.
• [0018] 2. Otherwise, the recorder compares the existing MKB on the media with its own MKB in step 104. If the MKB on the media is older, then in step 106 the recorder replaces the MKB on the media with its own. As part of that replacement, the recorder must re-encrypt all titles currently on the media with a key based on the newer (i.e. the recorder's) media key.
• [0019] 3. If the MKB on the media is more recent, then in step 108 the recorder uses the MKB on the media instead of its own. If the recorder has its own internal non-volatile memory, then it can store the more recent MKB in that memory, and then from that point on use the more recent MKB as its own MKB for content protection.

[0020] Thus, with the present invention, MKBs no longer have any practical restriction in size. Also, any piece of blank media can be used as content-protected media, as long as it has a unique serial number or media ID, so consumer confusion is avoided. (If cloned serial numbers were used, those pieces of identical media could be used to make unauthorized copies by just making a bit-for-bit copy.) Finally, since recorder-player devices already employ programmable read-only memory for unique device keys, having a unique MKB per device would only require slightly more programmable storage, not a new and costly disc manufacturing step. Therefore, with the present invention, the chance that media keys could become global secrets would be greatly reduced.

[0021] There are some subtleties, however. If the MKB changes, then every encrypted title key has to be updated, and recorders generally are not cognizant of all possible formats of content. They do not know where the encrypted title keys are stored for the unknown formats, and thus are not able to re-encrypt them when they change the MKB. This problem is solved simply by having different MKBs for different formats. The recorder only updates MKBs of the formats it understands. However, a “backup MKB” protocol may be defined so that content is not lost if a recorder fails during the updating. An exemplary backup MKB protocol is as follows:

[0022] If the encrypted title keys are in a single file, then the recorder renames the old encrypted title keys to a defined backup name before beginning to write the new encrypted title keys file via these logical steps:

• [0023] 1. Check to see if both a backup MKB and a backup encrypted title keys file exists. If they both exist then go to step 2, else erase the remaining backup file and exit.
• [0024] 2. If the current MKB does not exist or is corrupt then rename the backup MKB and backup encrypted title keys file to the current files and exit.
• [0025] 3. Decrypt the title keys in the backup title keys file using the backup MKB, and re-encrypt the title keys using the current MKB, writing the current title keys file.
• [0026] 4. Delete the backup MKB and the backup title keys file, modifying any nonce associated with the backup encrypted title key file.

[0027] In some applications, encrypted title keys may be found in more than one file. In that case, the recorder runs the backup protocol separately for each file, not deleting the backup MKB until all title keys files have been processed.

[0028] Further, if the MKB is simply a file in a file system, it might be difficult for the recorder to find it (i.e. for optical media, the disc drive authentication requires the disc to read the MKB, but from where?). Disc drives are not accustomed to understanding the format of the file system on the disc and would prefer to simply access data at fixed locations on the disc. This preference can be accommodated by having the disc format operation place the MKB at a pre-defined location on the disc, in addition to placing it logically in the file system. Subsequent MKBs can simply overwrite a previous MKB in the same place. Recorders must not accept discs that have not been correctly formatted, and must be able to format them themselves and then write an “authentication MKB”. Recorders must undoubtedly perform the formatting for other reasons. The authentication MKB should be in addition to all the format-specific MKBs, and the recorder must be prepared to update any MKB that it knows. It always knows about the authentication MKB.

[0029] Historically, attackers who want to use circumvention programs save old media for a down-level media attack, as they hope that those MKBs will be broken. This invention changes the nature of the attacks possible against the content protection scheme. For example, in the current state of the art, the attackers employ an attack where they save media that comes out when the scheme was first introduced, before there were any revocations. Once circumvention devices (e.g. rogue recorders) appear, they will be revoked for new media, but will still be able to use the old media. Next, the attackers ask compliant recorders to record content on the old media. The attackers then use the circumvention device to make unauthorized copies. This attack is somewhat obviated by MKB extensions, which the attacker must avoid, but MKB extensions are always optional.

[0030] In the present invention, the analogous attack proceeds as follows: the attacker buys devices (instead of media) that come out when the scheme is first introduced. These old recorders format media with old media key blocks. The attackers ask the old devices to record content, and then use the circumvention devices to make unauthorized copies. The attacker has to avoid using a particular media in a new recorder—the attack becomes even more difficult if the recorders have non-volatile storage for the latest updated MKB they've seen for subsequent writing use.

[0031] What if a rogue replicator clones the supposedly unique IDs of the media? In this case, in both the prior art and in the present invention, the only recourse is legal. Consider the legal situation in the current state of the art. If the replicator has licensed the content protection scheme and built cloned media, he is in violation of that license. If he is not a licensee, then he has violated the intellectual property of the content protection scheme: the copyrighted MKB, the trade secrets, and the relevant patents. In either case, the replicator might be accused of having circumvented “technical protection means” and be liable to prosecution under the U.S. Digital Millennium Copyright Act (DMCA).

[0032] The present invention allows the possibility that replicators need not be licensees of the content protection scheme. If the replicator need not be a licensee, then all media will be usable for content protection, and there will be less chance of user confusion. In this case, the content protection scheme's owners might have no status in court if a replicator is cloning, and protection falls back on the strength of the DMCA. However, replicators must always be licensees of the particular media format. If the format license makes the reasonable demand that unique IDs must actually be unique, then the legal situation reverts to the way it was before the present invention. It is just that the format owner, not the content protection scheme owner, is now the legally injured party.

[0033] If for some reason this situation is not satisfactory, the content protection scheme can add some licensable element to the media. The media ID might be divided into two parts, for example, a unique ID and an encryption of that ID with a secret key available only with the license. Player devices would be given the key so they can check that the two halves match. Players would only play licensed media. However, this license would presumably be less onerous to the replicators, because it would no longer restrict the number of replicas, and need not require an ongoing license fee. It is possible that all replicators would choose to be licensees under these terms, and consumer confusion would be avoided.

[0034] It is also within the scope of this invention to have the replicators initially record the authentication MKB at the time of media manufacture. In that case, the consumer confusion problem returns, but the security of the content protection scheme is increased as the attack mentioned before now requires both an old media and an old player to succeed.

[0035] A general purpose computer is programmed according to the inventive steps herein. The invention can also be embodied as an article of manufacture—a machine component—that is used by a digital processing apparatus to execute the present logic. This invention is realized in a critical machine component that causes a digital processing apparatus to perform the inventive method steps herein. The invention may be embodied by a computer program that is executed by a processor within a computer as a series of computer-executable instructions. These instructions may reside, for example, in RAM of a computer or on a hard drive or optical drive of the computer, or the instructions may be stored on a DASD array, magnetic tape, electronic read-only memory, or other appropriate data storage device.

[0036] While the particular READ/WRITE MEDIA KEY BLOCK as herein shown and described in detail is fully capable of attaining the above-described objects of the invention, it is to be understood that it is the presently preferred embodiment of the present invention and is thus representative of the subject matter which is broadly contemplated by the present invention, that the scope of the present invention fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope of the present invention is accordingly to be limited by nothing other than the appended claims, in which reference to an element in the singular is not intended to mean “one and only one” unless explicitly so stated, but rather “one or more”. All structural and functional equivalents to the elements of the above-described preferred embodiment that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the present invention, for it to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. No claim element herein is to be construed under the provisions of 35 U.S.C. 112, sixth paragraph, unless the element is expressly recited using the phrase “means for”.