HK1119825A - Reprogrammable security for controlling piracy and enabling interactive content - Google Patents

Description

Reprogrammable security for controlling piracy and enabling interactive content

This application is a divisional application of the patent application filed on 7/2004 under the international application number PCT/US2004/021621, No. 200480023948.3 entitled "reprogrammable security for controlling piracy and enabling interactive content".

Technical Field

The present application relates generally to securing the distribution of digital content and other data against piracy and other unauthorized use or redistribution.

Background

A wide variety of systems have been proposed to protect digital content. Most of these schemes encrypt the content to protect it from unauthorized use and copying when it is stored on media or sent over an untrusted communication channel. The decryption algorithm and keys are then managed by a trusted tamper-resistant software or hardware module designed to execute access control rules (which may be fixed or configurable) that dictate how the content may be used.

Content protection schemes are typically customized for a particular playback environment. For example, an anti-piracy system in a pure software streaming content player designed for a personal computer lacks the security benefits of tamper-resistant hardware, but is generally more conveniently upgradeable (e.g., if the user unloads the player and downloads updates from the manufacturer's website). Thus, the system provides less reliable security than a hardware-based player, but the consequences of the attack are relatively small because the upgraded security features can be exploited by modifying the content stream and requiring the user to upgrade his software.

In contrast, the protection methods embedded in consumer electronics hardware devices that play optical media are notoriously difficult to upgrade. Security challenges include: the long life of optical media (which prevents security upgrades that are not backwards compatible), the lack of a convenient and reliable way to deliver updates to the player, and the lack of standardization between player implementations. These difficulties coupled with the long life of playback devices and consumer expectations that all of the novel content is played on old players make introducing security upgrades extremely difficult. Thus, most consumer electronic devices provide little or no actual protection against copying, and the few content protection standards that are employed in consumer electronic devices are often simple, rigid solutions that provide less flexibility and renewability. Fig. 1 illustrates a typical content protection system of the background art. Content player 100 includes software in non-volatile program memory 105 that implements the player's security policy 110, decryption code 120, and player key 130. This code and key are used by the processor 140 to verify that the content read from the medium 150 is valid, and if so, to decrypt the content and provide the result to the output interface 160. Examples of protection systems like that illustrated in fig. 1 include: copy control schemes for digital audio tapes, Content Scrambling Systems (CSS) to protect DVD video, and CPPM schemes proposed for protecting DVD audio.

A number of different techniques are known in the background art:

and (3) access control policy:a wide variety of access policies and methods for specifying the policies are known in the background art. For example, the software protection system of U.S. patent No. 4,658,093 to Hellman uses a straightforward authorization code issued by the publisher. In contrast, U.S. patent 5,982,891 to Ginter et al describes a variety of very complex access rules involving a large number of participants. Standards for encoding access policies (for use with content distribution and other applications) such as PolicyMaker and x.509 certificate formats have also been proposed.

And (3) antivirus software:methods for detecting and blocking known viruses, trojan horse programs and other malicious code are well known in the art. These methods generally involve scanning for known virusesSuch as the properties of a known instruction sequence. These programs may operate in a number of ways, such as scanning files during startup, scanning files in real-time (on-the-fly), scanning programs as the programs execute, scanning memory, scanning new media, scanning network communications, and so forth.

Content protection system and DRM:a wide variety of content protection systems (which are sometimes also referred to as Digital Rights Management (DRM) systems) have been proposed. Background art DRM systems generally provide for distributing content in an encrypted form, followed by providing a decryption key or performing a decryption operation for a legitimate purchaser. Many features have been proposed or included in commercial DRM, including support for superdistribution (encrypted content can be exchanged between users), pay-per-view billing (including offline pay-per-view with reporting (reporting) over telephone lines), variable rates (different charges based on promotions, number or duration of use, requested user actions, user history, etc.), protection of various data types (audio, video, text, software, etc.), support for various formats and support for various playback device types (portable, set-top, computer-based with hardware assistance, pure software, etc.).

Copy protection:methods for copy protecting personal computer software are known and widely used for certain kinds of software, such as computer games. These approaches generally involve binding a software program to a physical medium that is designed to be difficult to copy (e.g., by intentionally incorporating errors or non-standard formatting that is difficult to copy). Other copy protection systems involve protecting the installation process, for example, by requiring a user to obtain an authorization code from a server. In some cases, copy protection features are designed into the system. In other cases, including copy protection systems for computer software, video tapes, and audio CDs, copy protection is implemented by producing media with non-standard encoding that allows playback on most players but interferes with most attempts to copy the media. The main design challenge of copy protection systems is to minimize the impact on legitimate users (i.e. to obtain higher playability and usefulnessUser acceptance) while preventing improper action (i.e., achieving good security) as effectively as possible.

A cryptographic function:a wide variety of basic cryptographic functions are known, including block ciphers, hash functions, digital signature systems (and other public key systems), key management systems, and so forth. For more information on the underlying cryptography, see Bruce Schneier's "applied cryptography".

Password enlightenment device:using block ciphers or other cryptographic functions, it is possible to construct a "cryptographic affordance" that applies a secret cryptographic transformation to any externally-provided input message and returns the result. The cryptographic revealer may be constructed such that an attacker who knows the algorithm and protocol of the revealer cannot computationally determine the key of the revealer. In addition, since the number of possible inputs to the enlightenment can be very large (for example, up to 2 for enlightenments constructed with 256-bit block ciphers)²⁵⁶) It is not possible for an attacker to predict or expect a response to a random challenge.

Interpreter, emulator and virtual machine:a variety of interpreted computer languages are known in the background. Some interpreted languages, such as Java, require a compilation process to convert source code into an executable or interpretable form. Instead, most BASIC interpreters operate directly on source code. Some interpreters allow self-modifying code, while others do not. Techniques for implementing interpreters and for simulating assembly languages are also known in the background art. For example, complex emulators such as Virtual PC and SoftWindows may run programs designed for Microsoft Windows on Apple Mac computers. Virtual Machine (VM) designs such as those used for Java and JavaCard are known, and it is also known that VMs can interact with native code (native code) on a computer or call other VM functions in different memory spaces. (many Java implementations provide these capabilities.) interpreted languages are commonly used in applications or where cross-platform compatibility is required, such as for creating processor-independent interfaces The device driver format of (1). (see, e.g., Writing FCode2.x Programs, Sun Microsystems, 1993, page 5.)

And (3) key management:a wide variety of methods for distributing and managing cryptographic keys have been proposed. A known device may have keys, group keys, public keys, private keys, certificates, etc. that are specific to the device. The keys may be distributed to individual devices, a selected group of devices (e.g., as described in U.S. patent No. 5,592,552 to Fiat), all devices, and so on. A device may contain a variety of different types of keys, including symmetric keys, public keys (e.g., to verify certificates and digital signatures), and asymmetric private keys.

Media:media technologies are known that provide tremendous storage capacity, low manufacturing cost, and good endurance. Examples of current media technology include compact discs (CDs, DVDs, etc.), magnetic media, flash memory, and ROM. Newer technologies such as holographic memories are also being developed. It is known that monolithic media may include many different types of data. For example, a compact disc (compact disc) may contain standard Red Book (Red Book) audio songs and data sessions for use on a personal computer (e.g., including software, compressed companion songs, images, video, lyrics, etc.). A compact disc for a personal computer may contain encrypted content and playback software necessary to play the content.

Network communication:complex data networks, including the internet, are known. These networks may provide flexible, reliable, high bandwidth data communications. Although networks with physical connections generally provide higher bandwidth, wireless communication channels are also popular.

Renewable security:in some cases, it is not practical to propose a security system that guarantees that all possible attacks can be prevented. Thus, there is a need to potentially renew security after an attack, for example by aborting use of any compromised keys and correcting vulnerabilities. Though renewable, anCompleteness is desirable, but many deployed and proposed systems lack any effective recovery mechanism for many kinds of attacks.

The sandbox technology comprises the following steps:sandboxing involves executing a software program in a controlled environment where the program is unable to perform any operations that may impair the system. Java "virtual machines" support sandboxing so that untrusted applets (applets) (such as those downloaded via the internet) can be executed.

A security module:many security systems use removable security modules so that security upgrades can be performed without having to expend money to replace other parts of the system. For example, removable security modules are used in many pay-tv systems.

And (3) software updating:a secure software update may be performed by receiving a proposed software update, verifying a digital signature or message authentication code that verifies the update, and then (if the signature is valid) performing the update. For example, it is known that digital audio players can receive code updates, verify a digital signature or message authentication code for the update, and update their code (if valid). Methods for ensuring that updates are applied in the correct order (e.g., using a sequence counter) and for recovering from failed or unsuccessful updates (e.g., by reverting to a previous software release or by activating a dedicated recovery code) are also known. It is also known that software updates may be delivered via a number of distribution mechanisms such as the internet, optical media, cartridge rom, etc. Software updates have been used to prevent pay-tv piracy by distributing code updates along with the signal to a descrambler, which applies and successfully executes the new code to calculate the correct decryption key for the next video segment. These updates are commonly used to prevent unauthorized viewing by disabling or even destroying unauthorized descramblers.

Steganography (Steganography): Steganography involves hiding information in data. For example, it is known to place encrypted data in an image or audio recordingOf the least significant bit. Because the lower order bits generally appear random, and the ciphertext produced by the strong encryption algorithm cannot be distinguished from random data without the key, an attacker who acquires this image or recording but does not know the decryption key cannot even determine if there is any hidden data.

Tamper-proofing:many methods are known for designing and constructing devices that are resistant to attacks. Tamper-resistant hardware is commonly used in systems that require protection from attackers reverse engineering devices or extracting keys from cryptographic modules. For example, Wave Systems sells microprocessor-based tamper-resistant integrated circuit products known as "Embassy" that can be integrated with a content player or general-purpose computer and used to secure digital content distribution by promotion. Methods for implementing tamper-resistant software have also been proposed (see, e.g., U.S. Pat. No. 5,892,899 to Aucsmith et al.)

Traitor tracing:traitor tracing schemes have been proposed to identify the source of a leak or attack, typically by tracing keys used in unauthorized devices back to the device specific to the consumer or the device that has been compromised.

Watermarking technology:a watermark is a signal embedded in the content that is detectable by a dedicated detector but does not affect (or minimally affects) the perception of the content by a person when played. Watermarks embedded in pictures, sound recordings and images have been used by copyright holders to indicate that copying is unauthorized. A "robust" watermark is known to withstand conversion between formats (including re-recording from analog output) and to provide varying degrees of security against attacks attempting to remove the watermark. Conversely, a "fragile" watermark has less or no ability to withstand format conversion, but is easier to design and can carry more information.

Although no anti-piracy system can completely prevent all possible attacks, the systems of the background art do not provide a practical solution to the solvable problems such as accidental piracy using digital-to-digital copying or high speed tearing down of the protected format into an unprotected format. Significant limitations of many systems of the background art include (without limitation):

depending on the global secret:many protection systems require that cryptographic algorithms, keys and other information required for decoding be kept secret. Therefore, the decoding process cannot be recorded in open standard literature without compromising the security of the system. Also, if there is a large number of implementations, an attacker could potentially corrupt the entire scheme by attacking the weakest implementation. (such attacks have recently occurred on DVD video protection systems.) although the system can be used in a closed single vendor environment, it is not standardized and does not provide effective long-term security.

Lack of standardization:content publishers have been enthusiastic about incompatible data formats and decryption algorithms. Different content protection systems allow different business models to be used, and publishers who have been enthusiastic about a model are likely to object to any security system that requires a different model.

Incompatibility with product type:many security features cannot be incorporated with all product types. For example, a downloadable software-only player for a personal computer cannot include tamper-resistant hardware. Similarly, frequent software updates are difficult to deliver to players without an internet connection.

A user interface:many proposals involve complex user interfaces. Security should be invisible to honest users. The user is likely to decline the scheme (e.g., obtain or enter an authorization code) that requires explicit user participation. In general, consumer electronic devices such as car audio and video disc players must be easy to use, as many users must be satisfied even if they do not read descriptive documents, are bothersome to technical problems, have poor eyesight or other deficiencies, or are unfamiliar with the language supported by the player.

Legal challenges:some security systems require a competition between competitors In a cooperative manner. Due to anti-Torass regulations, the cooperation may be illegal.

The manufacturer receives no benefit:manufacturers will object to increase player cost, time-to-market (time-to-market), prevent inclusion of legitimate features, or otherwise make their products less effective or less desirable security features. While advances in semiconductor technology are reducing the cost required to implement a security system, it remains difficult and expensive to design and produce effective tamper-resistant hardware. Thus, relying on the manufacturer to produce a well-implemented content protection system would fail unless it provides a real market advantage to the manufacturer that the supplied product (biasing) is safer.

Uncertain security policies:an effective security system must specify rules or other decision procedures for determining whether to allow or block a particular action requested by a user. In many systems, these rules or procedures are not well defined.

Inflexible security policies:it is desirable for a content protection system to have the flexibility to support different modes for different publishers, content types, scopes, playback environments, and so forth. The system should provide the necessary flexibility without becoming overly complex.

Weak long-term safety:the security system must be robust and flexible enough to remain effective for long periods of time. Background art content protection systems rarely last more than a few years as part of a high-profile format, whereas popular formats last more than 30 years.

Untraceability of attacks:if an attack does occur, the system should be able to identify the source of the attack so that the leaked (or misused) device can be withdrawn and prosecuted by the offender.

Disclosure of Invention

The present application is directed to various embodiments and aspects of a standardizable content protection system that can be implemented in a manner that provides flexible and updateable content protection across a wide variety of interoperability platforms. The system provides participants (manufacturers, publishers, artists, and/or consumers, etc.) with unparalleled flexibility in making decisions regarding security and functionality.

An exemplary player that can be used with the system, i.e., a device that wishes to decrypt or otherwise access protected content, includes several components. The first is a data or media input interface, such as for an optical disc drive. To initiate playback, the player loads a sequence of data processing commands from the input interface and begins executing those commands using an interpreter or other execution module. The execution environment preferably provides a tour-integrity language (a language that can execute any algorithms, subject to the player's memory, user interface, and performance constraints). From the execution environment, the content may query the player to determine the configuration of the playback environment and perform cryptographic operations using the player's key. The content can be designed so that playback will only be on players that provide satisfactory responses to queries. Publishers may also provide limited playback. For example, less secure platforms may provide CD-quality stereo audio or regular-definition images, while more secure platforms may provide more audio channels, high-definition images, higher sampling rates, and higher quality compression. Even after playback is started, playback can remain controlled by the data processing command of the content. An exemplary embodiment includes the ability to perform robust, substantially real-time (on-the-fly) watermarking. Allowing the content itself to control which data regions are played makes it possible to embed information in the output by selecting between versions of the output data with minor differences. Pirated copies can be traced back to a particular player by analyzing these differences.

Because the content contains and enforces its own security policies, emerging attacks can be handled by designing and distributing new content that is resistant. The flexibility provided by allowing content to enforce its own security policies also allows support for artist preferences, regional "fair use" provisions, and so forth. New player features can be easily added by adding new content-accessible player functionality.

From a business perspective, any content protection system that can be used to unite content publishers and consumer electronics manufacturers with the common goal of providing the greatest possible security needs to comply with the business and operational limitations of the publishers and manufacturers. The system disclosed herein allows publishers to determine their own security requirements, then allows the content itself to implement policies that take into account a variety of factors and determine whether (or how) to play in each environment. Also, manufacturers may be incentivized to design products that can provide good security and do not promote piracy, so that their consumers are accessible to the broadest content possible.

Drawings

Fig. 1 shows a media player using a content protection method of the background art.

Fig. 2 illustrates an exemplary media player using the content protection methods disclosed herein.

Fig. 3 illustrates the decryption portion of an exemplary embodiment.

Fig. 4 illustrates an exemplary embodiment of a player method for protecting access to non-volatile memory without the need for a centralized code signing authority.

FIG. 5 illustrates an exemplary verification process when attached to a non-volatile memory slot.

Detailed Description

FIG. 2 shows an exemplary embodiment of a player using physical media 200. The playback process is controlled by a processor 210 that can access the medium 200 through a media interface 205. When the media 200 is installed (e.g., when it is first inserted or re-initialized into the system, etc.), the processor 210 begins by initializing the media interface, reading the directory of media (tables of contents), and recognizing the supported protection systems. If so, the processor loads a smaller initial portion of the media 200 into the execution and data RAM 220.

The processor 210 uses the interpreter 215 to begin performing data processing operations specified by the loaded media portions. Interpreter 215 provides a predetermined set of data processing operations upon which more complex tasks may be performed. The interpreted language is preferably tour-Complete. A feature of the circuit integrity programming language is that algorithms that can be implemented in one such language can be implemented in any other language, and implementations will have similar asymptotic performance characteristics. Examples of roving integrity programming languages include (without limitation) C, C + +, BASIC, Fortran, Pascal, Java, and virtually all assembly languages.

The loaded portion continues by calling the procedure call provided by interpreter 215. Although the initial data loaded into RAM 220 may be relatively small, the code running on interpreter 215 may load additional data (including code) from the media through procedure calls, allowing more complex operations to be performed.

Other procedure calls allow the content to determine playback environment configuration 225. The content may therefore analyze the playback environment characteristics (e.g., player type, requested user action, etc.) to determine whether playback should continue. In an exemplary embodiment, if correctable problems are detected (e.g., if the media includes a security firmware upgrade for the player), these problems may be handled. If supported, the content may also query output interface 250 and, if supported, object/device 260 (e.g., amplifiers, digital speakers, speaker drivers, etc.) to check security features, load cryptographic keys, specify output parameters (e.g., specify reduced output quality if security is uncertain), and so forth.

In an exemplary embodiment, the content may also query a password affordance 230, which may be implemented in an external removable security module 235 (such as a smart card, etc.) to allow secure hardware upgrades. The affordance may also be implemented in, without limitation, the processor 210, other hardware in the player, media, additional devices such as speakers, and so forth. Password affordance 230 may provide verifiable evidence of the player's identity to the content. The result of the query to the affordance 230 may be used to decrypt subsequent content or portions of code, thereby providing a strong encryption guarantee that players without a valid key (or key revoked) cannot decrypt the content.

In an exemplary embodiment, the interpreter executes data processing commands specified by the content in the "sandbox," meaning that the content is not able to contact cryptographic secrets (such as the affordance key) that might otherwise compromise the player's security. Sandboxing is useful where not all content is necessarily trustworthy. For example, an attacker may try to generate malicious content that attempts to extract a cryptographic key from a player. (additional information regarding the exemplary password affordance and its operation is provided below.)

If the content determines that playback should not continue (e.g., if the user attempts to copy and the content is configured to inhibit copying), the content may report an error and deny the requested action. Alternatively, the content may control the rendering and/or output process to reduce the quality of the output, such that unauthorized copies are reduced in quality and therefore less attractive.

If the content determines that playback should continue, the content awaits a signal from the player that the specified playback should begin from a particular location (e.g., a particular track) on the media. Interpreter 215 processes the request using data processing instructions loaded into execution/data RAM 220 when the media is installed. If the content decides that playback should continue, it uses a procedure call to control the media interface 205 to begin loading the encrypted content from the appropriate location on the media 200. The content specifies valid decryption keys and parameters for the chunk decryption module 240, which chunk decryption module 240 retrieves encrypted content from the RAM 220 (or directly from the media interface 205) and decrypts it. The decrypted content is then provided to the output interface 205, which converts the content into an analog or digital format suitable for the target program or device 260. As playback continues, data processing instructions processed by the interpreter 215 may load new decryption parameters, specify new data blocks to be read from the medium 200, and so on. When playback is complete, the content may reinitialize RAM 220.

Additional information regarding the interpreter, playback system, and other embodiments and aspects is provided in the following sections.

Responding to attacks

Anti-piracy systems widely implemented in software and low cost consumer electronics are not able to prevent all possible attacks. The techniques disclosed herein may be used to facilitate the production of new content after an attack in a manner that substantially blocks existing attacks. While professional pirates may seek to constantly seek and install new circumvention systems, casual piracy will involve constant striving to develop and maintain attack tools, and thus will hopefully be more difficult than merely legally purchasing content. The following sections describe how the techniques disclosed herein can be used to handle certain common attacks.

The first attack involves attempting to perform unauthorized actions using the undisleaked player. For example, content may be authored to allow copying from the original media but not from the copy. If an attempt is made to copy the content from the copy (the content may identify this, for example, by detecting modifications inserted during the copying process or by comparing the sequence number and/or type of the current media with the original media), the interpreter code may prevent playback. Alternatively, the interpreter may allow content to be played with reduced fidelity (such as playing stereo audio with a 44.1 khz sampling rate even though multi-channel audio with a higher sampling rate is available) or by inserting additional anti-piracy warnings. Thus, by analyzing the information provided to the interpreter, inappropriate user requests can be detected and processed on a non-compromised player.

The second attack involves the leakage of the player's cryptographic key. If the player's cryptographic key has been compromised, an attacker can (at least theoretically) fully simulate the compromised playback environment by simulating the cryptographic revealer and (optionally) providing false responses to queries about the playback environment. Upon such an attack, security may be re-established by having the interpreted code in the future require at least one cryptographic key that is not provided in the compromised device. If a particular player model or manufacturer is the source of many attacks (e.g., because the player implementation has insufficient security), the publisher may produce content that cannot be played (or will be played at a reduced quality) on the platform.

A third type of attack involves leaking a particular piece of content or a set of topics containing similar interpreter security code. The attack can potentially be initiated by modifying the content itself to circumvent security checks or by generating a malicious interpreter (maleicous interpreter) that is customized to play the target subject. The attack may be coped with by applying different or better protection software in future content.

A fourth attack involves copying content from a protected media to an unprotected format and then redistributing the content in the new format. No content protection system can completely prevent such attacks, but the techniques and systems disclosed herein provide a powerful, flexible watermarking capability that can be used to trace a leak back to a particular device, which can then be revoked to prevent future attacks. Because the number of users actively uploading content for piracy is relatively small, piracy can be significantly reduced by identifying and revoking the players of these users. Very subtle differences can be introduced in the decrypted output by selectively skipping portions of the ciphertext. For example, in an exemplary embodiment, the content may be decrypted by a decryption module controlling the player and output a first ciphertext portion, followed by skipping a second ciphertext portion to watermark the "zero" bits. To watermark a "one" bit, the content may control the module to skip the first ciphertext portion and output the second ciphertext portion. By encoding a series of said bits, the content can be watermarked with any data available to the interpreter code, including (without limitation) the player identity, the cryptographic operation results, user action descriptions, output device information, etc. If a pirated copy of the content is found, the watermark can be analyzed to track the illegal copy back to a single player, which can then be revoked in future versions of the content. This capability is also applicable to law enforcement and forensic purposes, as it is possible to prove with certainty that a particular copy originated from a particular player. The features used to track copies can also be used to deter piracy, since one considering making illegal copies can be deterred by knowing that they can be identified, caught, and prosecuted.

Of course, no consumer-friendly anti-piracy system can reliably prevent all possible attacks in all environments. For example, audio and video may be recorded from the analog output. (a recorder without a watermark detector is available even though the watermark has been embedded in the content.) the data intercepted from the analog output can then be re-produced on new digital or analog media and redistributed without the original security features. Similarly, copies made by professional pirates who have the equipment needed to make accurate copies of media cannot be detected by the player, but the techniques and systems disclosed herein can help prevent media cloning. For example, disc manufacturer identifiers on media may be checked by content to ensure that honest or careless copying facilities are not spoofed by pirates. The media type identifier may prevent content sold on read-only media from being redistributed on recordable media. For players with internet, telephone/modem, or other network support, the content may obtain authentication, e.g., from a server, prior to playback (or first playback) to verify that the media is valid. Players with non-volatile memory may even store a table of media serial numbers known to be bad, which the content and/or player may query to determine whether the media has been revoked.

Querying and controlling playback environments

The content may be configured to decide whether it will allow itself to be decoded. To assist in making this determination, the player may provide the content with information regarding the playback environment. Although very limited information, such as the actions requested by the user and the player model, may be sufficient in many situations, more detailed and accurate information is needed so that the content can be more fully evaluated as to whether playback should continue. Although the specific information and capabilities provided to the content depend on the player implementation, certain exemplary functions and capabilities that may be provided to the content are described below (without limitation). It should be noted that for players constructed from multiple connected components (such as output ports, connected output devices, operating system device drivers, security modules, etc.), some or all of the following information may be provided for these connected devices as well as the main portion of the player containing the interpreter.

Security support information:security specification version, supported query functions, and/or security module form factors (alternative hardware, embedded hardware, updateable firmware, ROM firmware, PC software, etc.), etc. (exemplary cryptographic processing functions and playback control/decryption functions are discussed in detail below.)

Manufacturer information:name, identifier, web site, public key/certificate, manufacturing lot, manufacturing date/time, manufacturing area, manufacturing country, manufacturer address, technical support contact information, and/or manufacturer assurance information, among others.

Device information:production line, serial number, model number, firmware/software version, device public key/certificate identifier, GPS location or other physical location/area, codec type of content supported (content supported), network/Internet support information,Network address, device phone number, IP address, watermark support, interpreter performance level, security authentication level, device vendor, device retailer, device form factor, and/or security specifications, among others.

User information:user name, geographic region, country, address, GPS location or other physical location/region/country/etc., user phone number, IP address, e-mail address, web address, preferred language, tolerance to disputed material, preferred payment method/account number, payment limit, purchase history and/or privacy preferences, etc.

And (3) media control:query media format (recordable vs. non-recordable), media number, recording device type, recording device owner, recording device number, recording device security information, and/or recording device watermark checking capabilities, etc. The functionality may also allow reading from, writing to, formatting for, testing for, and/or ejecting from the media, etc. The additional functionality may provide for application of cryptographic functions or other special capabilities supported by a particular media format.

Requested user operation:e.g., play, record, convert to a new format, load into a portable device, make a first copy, make multiple copies, and/or play/record simultaneously, etc. The content may also be given the ability to initiate or modify the requested operation.

Outputting information:information about output ports, output port configuration, output port security features, connected devices, output data format and/or output data quality/resolution, etc. If supported, the content may query the output device directly to obtain additional information about the device, and/or request a cryptographic operation, etc. The player may also allow the content to modify these parameters, for example, to specify a reduced quality output if security is poor.

Environment:identity/hash value/version of other running programs and device drivers on the platformThen, the process is carried out; the contents or hash value of the memory; versions of installed attack detection modules; the system scans the results of the attack and/or the state of the tamper detector, etc. These functions may also allow the content to modify the memory, e.g., to correct security vulnerabilities in other programs.

Time:date, time zone, elapsed clock cycle count, time since last reset, time since manufacture, time since last security upgrade, time since last battery replacement and/or estimated remaining battery life, etc.

And (3) connectivity:determining player communication capabilities, checking current connection status, establishing network connections, establishing modem connections, specifying critical status for establishing network connections, checking/specifying connection security features, transmitting data, receiving data, closing and/or idling connections, and so forth.

A user interface:displaying user messages, displaying lyrics, displaying graphical images, printing graphical images, displaying advertising/promotional messages, identifying available user interface controls, obtaining user input, playing speech to the user using the player's voice synthesizer, and/or reporting errors, etc.

Watermark control:selecting a content area to be output, selecting an external watermark algorithm, controlling an external watermark detector and/or checking a mark detector (mark detector) status, etc.

And (3) the other:player/playback status information, pay-per-view billing control (e.g., based on player funding source), error handling, playback termination, protection of non-volatile memory support (see below), application of player firmware updates and/or invocation of external modules (such as dynamic link libraries), and the like.

Some standardization of functions and parameters is useful to ensure interoperability between implementations (e.g., so that content can function effectively in the player environment designed after the content was originally published) and to simplify the task of editing secure content. Standardization is particularly useful for functions where multiple different manufacturer's products will provide the same type of information or operation. For example, the functionality and response codes used to allow content to determine player form factors (home audio/video, portable, automotive, pure personal computer software, personal computer software with hardware assistance, professional studio, cinema, etc.) may be standardized. An additional benefit of standardization is that manufacturers are prevented from trying to avoid security control by reporting related risk-related (risk-related) information in a non-standard format that is not understandable by pre-existing content.

Of course, the system may also be configured to allow manufacturers to add ownership functionality for use by the content manufacturer to whom it is selected. The ability to add new functionality is particularly valuable to manufacturers who wish to add new features to their products, as they can add these features and then establish a collaborative business relationship with the content publisher to support the features. The embodiments can be easily extended while maintaining backward compatibility (if desired).

The manufacturer is responsible for providing accurate information to the content. While content is generally not able to directly verify the accuracy of most of the information it receives, this is not strictly necessary where the manufacturer has a strong incentive to ensure that this information is correct. For example, a publisher may prevent its future content from being played on products manufactured by reputable manufacturers.

While it may be beneficial for the player to provide cryptographic authentication for the information provided to the content (e.g., by including a digital signature issued using an authenticated player or manufacturer key), such authentication is not mandatory for most data. Cryptographic authentication is more important for other parts of the system or output devices connected via potentially untrusted interfaces, such as digital speakers requiring high quality digital audio data, so that malicious devices that impersonate trusted devices can be detected and avoided.

Cryptographic processing

In addition to providing information describing the playback environment, the exemplary player also implements cryptographic operations that may be invoked by the content. These operations may have a behavior similar to a cryptographic affordance, allowing the content to provide input data (e.g., 64-bit blocks of plaintext) and return the results of the cryptographic calculation. In an exemplary embodiment, the input for the cryptographic calculation includes at least a key (whose value is generally unknown and content is inaccessible) and input data specified by the content.

Examples of cryptographic primitives (unlimited) that may be provided to the content for purposes including (unlimited) authenticating the playback environment, deriving content decryption keys, and so forth are as follows:

block cipher revealing device:the enlighters encrypt (or decrypt) an input message using a secret key, producing a ciphertext (or plaintext) result.

Hash function revelator:the input message is typically hashed using a secret key (e.g., using an algorithm such as HMAC-SHA) to produce a result.

Digital signature revealer:the input message is digitally signed using a secret (private) key to produce a result. The functionality may also provide the content with a public key and its certificate.

Random number generator:the random number generator may provide information that the content is unpredictable, for example, for use in preventing reply attacks in online connections.

The mathematical function is:basic mathematical operations may be provided to help content optimize its computational process. For example, an optimized modular multiplication or exponential function may be used by the content to perform the RSA algorithm of U.S. Pat. No. 4,405,829 to Rivest et al to generate and verify digital signatures and encrypt and decrypt messages.

Optimized cryptographic primitives:optimized implementation of standard cryptographic algorithms can help improve performance. These operations may be used to help decrypt or hash a data block that includes an (unrestricted) area of interpreter code space or a section of content loaded from the media.

And (3) decryption control:if the content determines that playback is authorized, the interpreter code may initialize the content decryption module with the correct decryption key for each piece of content. In addition, the interpreter code may specify the portion of the content that should be rendered or skipped (e.g., to allow real-time watermark insertion during playback). To ensure synchronization between the interpreter and the content stream from the media, the key change (or skipped area) can be predefined and then triggered by a signal in the content. For example, an exemplary embodiment may allow the content to specify a 64-bit value that triggers a key change when it occurs in the ciphertext, the number of ciphertext bytes to skip after the key change, and a new key value to be used.

And (3) key management:these functions allow the content to decide which keys are known to the player.

In an exemplary embodiment of a cryptographic affordance operating without incorporating random parameters or other such variable data, the system may be configured such that the expected result of a particular input may be pre-computed (e.g., when the content is produced). The publisher may thus program the content to submit the selected input to the affordance, then verify that the expected result has been obtained. A malicious player lacking an authorized cryptographic key will not be able to calculate the correct affordance response. Since the number of possible revealer inputs is enormous (e.g. 2 for a revealer using a block cipher with a block size of 128 bits¹²⁸) It is practically infeasible for an attacker to pre-compute or store the results of all possible queries.

In addition to authenticating valid players, cryptographic affordances may also be used to identify invalid players. For example, if a key extracted from a legitimate player is used for unauthorized purposes, the content may be authored such that it will be denied to play on a player that includes a revoked affordance. Since the content will not play without a valid key, an unauthorized player must include the stolen key. However, by using these stolen keys, unauthorized devices expose their state to new content that is aware of the leak.

A wide variety of methods may be used to incorporate affordance results or to check whether a particular affordance query response is valid. The simplest approach is to perform only a comparison with the expected value. Because this can be circumvented (at least theoretically) by an interpreter that appears as a malicious design that appears to all comparisons to match, the content may include "false" comparisons that are expected to fail or other such tests designed to defeat the malicious interpreter. The revealer itself may also be used to decrypt the code or to affect the self-modifying code. For example, the input to the revealer may be an encrypted version of the desired code. Depending on its configuration, the affordance thus allows a content publisher to include it on media code that can only be decrypted by an authorized player or subset of players, thereby helping to make the code of the content unavailable to potential attackers. Another way of using the revealer is to use its output as a cryptographic key or to use it to derive a key. These keys may then be used, for example, to decrypt code, content, other keys, or any other data. This flexible decryption capability can be used to implement a wide variety of protocols and strategies in the content. For example, if the player has keys of sufficient classification, the content can be programmed to use a scheme such as the methods of Fiat and Naor (see broadcast encryption of a. Fiat and m. Naor, editorial Douglas stunson Cryptology, editor Douglas stunson, p.480; Springer Verlag, 1993). Even sophisticated access control systems such as those described in U.S. patent 5,982,891 to Ginter et al (provided, of course, that the player provides the necessary user interface, network, data storage and cryptographic functions) may be implemented as desired.

For production content, publishers may benefit from being able to access the affordance input/output pair. In the case of an enlightenmer using the private key of an asymmetric cryptographic system such as RSA, the publisher simply takes the public key and uses it to perform the inverse of the enlightenmer operation. For symmetric affordances constructed using block ciphers, the player manufacturer may calculate the inverse of the symmetric affordances provided in each player for the publisher. For example, if a player enlightenmer decrypts a 256-bit data block with one secret key using a block cipher, the manufacturer may provide the publisher with access to the corresponding encryption function. Because access to the reverse affordance does not allow for revealing the revealer, the manufacturer may provide the reverse affordance calculation via a publicly accessible web server, e.g., using SSL. The manufacturer may also provide the publisher with output from randomly selected affordance inputs. (although manufacturers may provide publishers with actual enlightener functions as implemented in players, these functions can potentially be misused in constructing unauthorized players that emulate legitimate players.)

The particular method used to distribute the keys to the player and the manufacturer depends on the particular embodiment and security objectives. For example, in one exemplary embodiment, the player is assigned a variety of symmetric cryptographic affordance keys, including (without limitation): a player symmetric key (pseudo) randomly selected from a larger global pool of said keys; player-specific symmetric keys generated by the manufacturer (pseudo) randomly; a symmetric key unique to the manufacturer, player model, etc.; and/or a symmetric key that authenticates players that do not have particular characteristics (e.g., are not manufactured by a particular manufacturer). In this exemplary embodiment, the content may identify which keys are implemented in the player by calling a separate function that may return a list of supported keys. The player may also contain an asymmetric key. For example, in an exemplary embodiment, the player has: player-specific public/private key pairs; a player certificate issued by the manufacturer by signing the public key of the player using the manufacturer's private key; a certificate issued by a root key issuing authority (root key issuing authority) that verifies the manufacturer's public key; a public key for authenticating a request to access a secure storage area of the player (see below); and/or a public key for verifying a player firmware update.

In an infrastructure involving multiple player manufacturers, it may be helpful for one or more central management organizations to manage keys for players, manufacturers, and so forth. The central administrator may also help enforce minimum security standards, ensure that the player provides accurate information to the content code, retain keys for new manufacturers (so that their products can play old content), track leaked keys, perform cryptographic affordance operations for content publishers, and so forth.

Secure memory and counter

The memory available for content is typically volatile, providing a "clean" execution environment for the content each time it is run. However, for some features, it is useful for the content to be able to store data between plays and between themes. To meet this need, players may provide content with a secure, non-volatile memory for maintaining state between plays. The memory may require additional security protection to ensure that only authorized interpreted code is able to read or modify the non-volatile memory contents. It is important for the publisher to secure the non-volatile memory so that, for example, this memory can be trusted to track offline pay-per-view history for later billing. It is not sufficient to have only one key on the media to unlock each memory slot, since this key will soon be discovered by a pirate, compromising the security of all player's memory slots. Thus, an embodiment provides clear cryptographic authentication of the code accessing these secure non-volatile memory areas.

In this embodiment, the player includes several blocks of non-volatile memory that are locked by default (i.e., read and write are denied). The player also contains a public key for authenticating the request to unlock the memory bank. To gain access to this memory block, the content invokes a function that takes as input the digital signature of the code block authorized to access the memory. This signature can be verified using a public key embedded in the player and specifies the memory bank to be unlocked and the access privileges granted in each portion of the bank (arbitrary read, arbitrary write, increment, decrement, zero, etc.). The interpreter verifies the digital signature and (if the signature is valid) unlocks the memory and executes the digitally signed code. An example of this process for offline pay-per-view content charging with occasional (e.g., monthly) audits is shown below:

(a) publisher X negotiates control of a 4-byte counter in the non-volatile memory of the player of manufacturer Y with player manufacturer Y.

(b) Publisher X writes a function for the interpreter that checks the contents of the memory. If the value is below the payout limit, the function increments a counter. Otherwise, the function establishes an internet connection with the publisher, transmits a payment request including the counter value, the random number, and payment information (such as a credit card number or other funding source stored in the player). If the publisher accepts the past purchase indicated by the counter plus the payment of the current purchase, the publisher transmits a cryptographic authorization to the player to clear the counter, the player verifies the cryptographic authorization and, if valid, zeroes the counter. The player ends by relocking the memory and returning a code indicating success or failure.

(c) Manufacturer Y digitally signs the memory update code with parameters identifying the memory region, access privileges, etc. of publisher X.

(d) Publisher X manufactures content including the signed code and distributes it to the users.

(e) The user's player begins loading content that provides the user with a purchase option. If the user refuses to purchase, playback will not continue.

(f) The content calls a memory unlock function using pointers to the code written at step (b) and the digital signature generated at step (c).

(g) The memory unlock function attempts to perform the purchase as described in step (b) and reports success or failure.

(h) If the purchase is successful, the content is played for the user. Otherwise, playback terminates.

Of course, more sophisticated purchase mechanisms may be employed by using the security counter mechanism described above. The only real limitation on what can be implemented in the content is the ability from the player and the creativity of the publisher.

Various storage technologies including, without limitation, flash memory, magnetic storage devices (e.g., hard disks), battery-backed RAM, and the like, may be used with the systems and techniques disclosed herein. (many methods are known in the background for providing non-volatile storage and for encrypting or otherwise protecting the storage.) secure storage may be located (without limitation) outside of the player, including (without limitation): in a removable module such as a smart card, in an attached output peripheral such as speakers, a display, a remote device in a home network, etc., remotely over a computer network, etc. For example, memory block allocation may be provided based on available space, configured/recycled in a guaranteed manner (e.g., by slot number), or based on priority. Because clearing or freeing a memory slot may result in the loss of unreported pay-per-view records, content may be given the ability to specify the conditions for a rewritable slot. For players that can play multiple themes simultaneously but have only one set of non-volatile memory slots, a locking mechanism may be required to ensure that one piece of content will access a slot that is being modified by another piece of content.

In one embodiment, the prepaid smart card is purchased by the consumer and inserted into a slot on the player. The card contains a plurality of write-once memory slots into which the player can write an identifier corresponding to a pay-per-view content theme. Once written, the content identifier is incorporated into a cryptographic affordance calculation implemented in the card. Thus, by verifying that the correct affordance already exists before allowing playback, the content can verify that the purchase has been completed.

It should be noted that the general method described above for authenticating calls to player functions is not limited to use with secure counters. For example, the same approach can be used to secure access to special player features that are only available to authorized publishers. Because the approach provides a general, but extremely flexible, approach for securing access to computational functions, it also has applicability that is different from other aspects of the techniques and systems disclosed herein.

Password-based security features versus language-based security features

The security policy may be enforced in a number of different ways. Cryptographic protection allows content to be constructed such that a revoked or unauthorized player will not have the cryptographic keys necessary to decrypt the content. An unauthorized player cannot access its content without a key (provided, of course, that a valid password is used). This approach is relatively inflexible as it only provides the content owner with the ability to block playback on a particular device. (although more complex embodiments may use different key sets to provide more detailed control, key-based control lacks the flexibility needed to address more complex access control challenges.) however, it is extremely effective in dealing with situations where a particular player has leaked or otherwise been deemed to be untrustworthy to have the ability to decrypt content.

In contrast, language-based control is less effective in situations where the player has been compromised (or is completely untrusted for some other reason), but it can implement extremely complex security policies. As mentioned previously, the content may analyze the playback environment and invoke a cryptographic affordance and refuse to play if the result is deemed unsatisfactory. This approach provides virtually unlimited flexibility, making it ideally suited to control the risks involved in playback on players that typically behave honestly but can support operations on particular content that some publishers may wish to prevent, such as breaking down into an unprotected format. Although attackers can (at least theoretically) analyze and attack individual segment contents (especially if the code of the content is poorly written), these attacks cannot be generalized and can be reliably countered by careful use of cryptographic affordances. Furthermore, the decryption control capabilities described herein enable publishers who observe pirated copies of their content to identify devices that have been compromised and produce new content that is not vulnerable to attack.

Progress of the development

There is a need to provide a distribution infrastructure that remains secure for long periods of time to content owners. Previous content protection systems have failed extremely in this regard; while implementers initially are best efforts at security when seeking support for new formats by content owners, the level of security tends to decrease significantly after one format ensures success. This downward trend is caused by a number of factors, including: more implementations can be attacked (increasing the likelihood of selling vulnerable products), the need for piracy increases as more protected content becomes available, and the sophistication of the attacker increases. Exemplary embodiments of the systems and techniques disclosed herein may be configured to allow content owners to continue to specify how their content will be protected even after the media format has been standardized, while allowing for virtually unlimited renewability so that security is not forever lost if an attack is discovered.

If the security policy is not static, the manufacturer has a continuous long-term drive to provide effective security. For example, the content owner may have the ability to block playback (or prevent high quality playback) on devices where keys have been compromised or products that are commonly used for piracy. Thus, unlike conventional systems, product manufacturers are unable to sacrifice security in competing to offer their products at the lowest possible price, as consumers will also seek products with robust security, as these products will provide the best and most reliable playback experience.

Even a well-intentioned manufacturer may accidentally produce a product that later is found to have a security flaw. Thus, we disclose a variety of methods that can be used to respond to leaks and security vulnerabilities. For example, player cryptographic keys and software may be updated using digitally signed code or key updates. These updates may be delivered to the player on a medium containing software that performs the key updates. For example, if a legitimate user's player is revoked because the previous owner compromised its security, the new owner may dial the technical support phone of the product and obtain a new key. (of course, customer service personnel may wish to obtain certain user information such as name, address, credit card number, telephone number, e-mail address, IP address, etc. to prevent pirates from dialing a call to request a new key for unauthorized use.) updates may also be distributed via the Internet (or other network connection), modem calls, input via a remote control or keyboard, and so forth. Of course, updates should be cryptographically protected whenever possible, so that an attacker cannot use the update process to inject leaked keys or otherwise attack the player.

Another way for manufacturers to reduce the consequences of leakage is to include a removable security module, such as a smart card. The smart card will implement some or all of the cryptographic affordances as well as other security-related functions provided to the content. If a leak does occur or if a security defect is found, it is possible to replace the smart card without replacing or upgrading the entire player. It should be noted that it is possible to provide only a smart card slot and not deploy a smart card until necessary for security reasons. To prevent the smart card from being removed from a legitimate player and used in a malicious player, the smart card may be cryptographically contacted to the receiver (e.g., by having it share a symmetric key) before the player and/or card are sent to the consumer.

Production and DRM

It is reasonable for the content owner to focus on any new costs involved in producing the content. The techniques and systems disclosed herein may be employed to avoid new significant costs of the fabrication process if simple security measures are used. While developing content to enforce complex security policies would clearly require more development and testing effort, this expense is entirely optional. (other protection systems eliminate this option altogether, forcing all content publishers to use the same security system, policy, etc.)

Of course, because the systems and techniques disclosed herein also allow third party DRM vendors to provide security modules and production systems, publishers need not develop security systems autonomously. These vendors will compete to gain publisher business by providing the best features, the best security, the lowest cost, the most flexibility, the most ease of use, the best performance, the smallest code size, the broadest scope of revocation lists, and so on. The techniques and systems disclosed herein may serve as a platform upon which content owners are able to make their own security decisions.

Watermarking and leakage tracking

In most conventional watermarking methods, the mark detection process is standardized and implemented in a large number of widely used products. This static algorithm unfortunately poses a serious risk, as knowledge of the detection algorithm typically allows an attacker to remove the watermark without seriously degrading the quality of the content. In an exemplary embodiment, the systems and techniques disclosed herein may include real-time watermark insertion, which is not susceptible to common mark removal attacks, since the mark format, encoding process, and detection process are all chosen by the publisher.

In an exemplary embodiment, a publisher (or more precisely, a control program written by the publisher) wishes to embed certain information in certain output content. Each bit of this information may be encoded by decrypting and outputting either the first content portion or the second portion. These portions may be different encrypted areas on the media and may be encrypted using different keys. The differences between these parts may be chosen by the publisher at the time of making the content and may be any difference from minor to complete variations. Since there is no predetermined relationship between the two parts, a pirate who only knows one part (including the decryption key of that part) cannot decide on the other part.

Because cryptographic controls and program-based controls can be used to select which regions are decrypted, an attacker cannot decide what a replacement region contains. In practice, the content may be designed such that an attacker cannot even identify if an alternative region is present, e.g. by encrypting the control code (so that different players use different codes) and by including a dummy region that is decryptable by no player or only a few players.

In an exemplary embodiment, the content is edited such that only a subset of all players have the keys required to decrypt each version of an area of the content, whereas substantially all players have the keys required to decrypt at least one version of the area. Thus, by analyzing unauthorized copies of this area, the publisher can determine information about the attacker. It should be noted that this holds even if an attacker tries to analyze one (vulnerable) program and decrypt more than one alternative region, since the resulting combination of regions still reveals to the publisher which versions are decrypted. Finally, the only reliable way for a user to avoid exposing their identity (or the identity of their player) to the publisher's anti-piracy enforcement specialist is not to participate in piracy from the outset.

This general marking method is different from conventional watermarking because the mark detection process does not need to be standardized. This difference allows for significantly increased security; in fact, it can be shown that there is no common attack on this marking scheme. Furthermore, because the watermarked bits create differences in the output, these watermarks may be extremely robust and may be designed to survive digital/analog conversion, editing, format conversion, malicious attacks, and so on.

The decision on how to configure and use the content tagging capability is typically made by the publisher. Some artists may wish to avoid any technique that would make any modification, however small, thereby precluding the use of watermark features on their work. In other cases, certain types of content are widely pirated and are suitable candidates for a large number of uses of marking capabilities. Although the sections are usually chosen with only slight differences, the choice of which alternative versions to encode, how to choose between the possible output versions and the management of the decryption keys of the sections are content controlled. Because the tagging capability is controlled by data processing instructions in conjunction with the content, the techniques may be used for other features, including (without limitation): implementing a lottery (sweepstake) in which the winner's player outputs a congratulatory message, delivering security warnings to users whose players are not secure enough, and providing certain users with delivery content.

Of course, other watermarking schemes may also be used with the techniques and systems disclosed herein. For example, a traditional watermark (for which the mark detection algorithm is standardized) may also be embedded in the output by the code of the content or by external watermark embedding circuitry (which may or may not be content controlled). Similarly, a watermark in incoming content may be read out (again, by the code of the content or by an external detector), for example to detect attempts to make unauthorized copies or to introduce unauthorized content. The selection of which watermarks to embed and how to respond to the detected watermarks may be implemented in the player and/or the content.

Example migration path: CD audio

Today, the vast majority of digital content is distributed in unprotected or minimally protected formats. For example, the CD audio standard does not include an iterative feature, and the protection scheme in DVD video has been largely undermined. Since legacy media players do not support sufficient security, they need to be upgraded or replaced. The success of new security systems depends on building a huge number of compatible players.

By combining the techniques and systems disclosed herein with existing methods for manufacturing copy protected CDs, it is possible to manufacture backwards compatible CDs. The CD will be formatted with a non-standard CD to produce an optical disc that plays correctly on most audio CD players but confuses computer-based ripping software. Authorized (e.g., licensed) personal computer software may also play the optical disc by correcting portions that are incorrectly read or otherwise confusing the computer. Playback is thus allowed on (most) legacy audio players, since they can play non-standard (copy protected) red book audio portions, and playback is allowed on a personal computer with appropriate player software, which may for example be included on a CD or downloadable via the internet. While long-term support of backwards compatibility to existing CD audio players may introduce additional security risks, it may be beneficial as part of a long-term policy that encourages the deployment of audio players that may play new secure formats, so that (eventually) content may be sold only in secure formats.

Example (c): high definition DVD

Copy protection systems used by current DVD video players have been largely compromised. Because millions of DVD players are sold and cannot be upgraded to new protection systems, there is no straightforward way to upgrade the current DVD format without giving up support for these old users. Fortunately, the installed base of a DVD player is only designed to support "standard" definition television (e.g., 525 lines for NTSC, 625 lines for PAL, etc.), but does not support the higher quality signals provided by High Definition Television (HDTV) formats. Because legacy players do not support HDTV, the new security features disclosed herein can be incorporated on DVDs that support HDTV.

In an exemplary embodiment, the player will have a user accessible media input (consisting of a motorized tray for one or more optical disks) that loads the media to a spindle where it is rotated and read using a laser. Data read from the medium is transferred to a microprocessor-based circuit that analyzes the disc encoding to determine disc capacity, formatting type and security method. If the optical disc is a legacy (low resolution) DVD using a legacy security scheme (CSS), the optical disc is played using methods known in the background art. If the disc is a high-density DVD using a programmable security method as disclosed herein, program code (data processing instructions) for the security policy of the content is loaded from the disc and executed by the player. The player may optionally also support low density DVDs using improved security and high density DVDs using legacy protection methods (although there is generally no benefit to using a security scheme that has been significantly compromised for new content). The quality of the output from the DVD player can be controlled by the content. For example, if the player and/or HDTV output device do not provide sufficient security, the content may choose to output a lower resolution output. In this case, the content may, for example and without limitation, control the player to down-convert the HDTV signal to a lower resolution (e.g., using a downgrade module specifically designed for this purpose), provide only the keys needed by the player to decrypt the lower resolution portion of the signal (and reject the keys needed for the higher resolution portion), or control the player to output a lower resolution version of the content encoded on the media separately from the higher resolution version.

Interpreter architecture

In an exemplary embodiment, the interpreted language is based on the DLX assembly language. Basic DLX processor architectures are well known in the background (see, e.g., Hennessy et alComputer Architecture：A Quantitative Approach，Second edition). Code executing in the memory space of the interpreter, which in an exemplary embodiment consists of 8 megabytes of RAM, is sandboxed so that it has access only to this memory and the register set of the processor. Invalid instructions (or other operations) may be handled as NOPs (i.e., do nothing) or may trigger a exceptionOften (exception). Similarly, an out-of-bounds (out-of-bounds) memory access may trigger an exception or may be corrected (e.g., in the case of a 32-bit read from an 8 megabyte address space, wrap-around the out-of-bounds access to the beginning of the memory by logically multiplying the address by 0x007 FFC hexadecimal and ensuring 32-bit alignment).

The DLX "trap" instruction is used to provide for the use of external procedure calls. The "trap" instruction calls operations in the player that are extendable outside the sandbox (i.e., beyond the registers and memory accessible by normal instructions). For a description of the operation, see the section "query and control playback environment".

It is also possible for dedicated hardware embodiments to use an ASIC or FPGA (or other hardware) implementation of the DLX processor instead of a software-based interpreter/emulator, in which case the "trap" instruction may be configured, for example, to trigger the processor to enter a higher privilege level, expand its address space to include a ROM or EEPROM region (e.g., by enabling additional address lines), store a return program counter (return program counter), and jump to a predetermined address in the expanded address space for further processing. The higher privilege level may also enable additional instructions or capabilities in the processor core, such as the ability to interact with external peripherals (e.g., non-volatile memory, cryptographic accelerators, key management components, optical media drives, data networks, satellite receivers, etc.). Memory protection capabilities in hardware implementations may include limiting the number of address lines (thereby preventing over-bound access) or using other memory protection methods known in the background. After the "trap" call is completed, the processor will reduce the privilege level and continue executing the content code.

In an exemplary DLX implementation for decrypting video distributed on high-density optical discs, "trap" operations are provided to allow content to read data from the disc. To load data from a physical medium, the content code typically specifies an address (e.g., a sector number on a disc), a target address of the data in DLX memory space, an amount of data to be loaded, and (optionally) decoding parameters (such as error correction polynomial)/parameters, decoding keys, and so forth). The content may use the data to perform any manner of processing steps, even including executing the data as code. Because optical drives, hard disk drives, and other data sources typically have significant latency (especially when performing operations such as seeking new tracks), separate "trap" operations may be used to pre-specify areas that are expected to need, request data, check the status of pending requests, and/or actually load data into the DLX memory space.

The content code may also invoke a trap operation to perform high speed cryptographic operations on memory. For example, an exemplary bulk decryption "trap" operation utilizes the AES encryption algorithm and allows content to specify (a) an exponent selected from among secret keys stored in (or accessible to) the player, (b) an encrypted key, (c) an address of data to be decrypted in the DLX memory space, and (d) a length of the data to be decrypted. trap (a) decrypts the encryption key received from the content using the key identified by the exponent value, and (b) decrypts the specified number of blocks of data at the indicated address using the AES algorithm in ECB mode using the decrypted key. The key-decryption-key that may be selected by the index may include keys stored in the player (including without limitation player-specific keys, manufacturer keys, group keys, media keys, etc., which may be stored in a cryptographic capable internal tamper-resistant chip and internal non-volatile memory as appropriate), keys stored in an external device (including without limitation cryptographic modules, optical disc drives, devices/servers accessible to a remote network, displays, speakers, etc.). To determine which keys are available, the content code may analyze the content such as the type of player, the serial number of the player, a list/description of keys included with the player (and optionally digitally signed by the player manufacturer or a trusted party), data obtained over the network, and any other available data about the player or playback environment (see the "query and control playback environment" section). Any manner of other cryptographic capabilities may also be provided by the content to the player, including (without limitation): encryption, decryption, symmetric algorithms (stream ciphers, block ciphers, hash algorithms, message authentication codes, etc. with any mode of operation), public key algorithms (signature, authentication, encryption, decryption, key management, zero knowledge (zero knowledge) operations, etc.), key and certificate management, etc.

The content code may perform additional processing (or pre-processing) operations on the decrypted results. For example, an XOR operation may be performed to convert the ECB decryption result into a CBC decryption result. A descrambling step may be applied to prevent pirates from decrypting the content using the key extracted from the player without executing their interpreted code. Examples of applicable steps include (without limitation): switching (toggle) bits, changing using simple binary operations, reordering blocks, placing or inserting offsets/addresses (e.g., to combine a data stream that conforms to MPEG-2 or other video compression standard), applying public key operations (such as modulo square or cubic with a complex number), applying symmetric cryptographic operations, and updating internal checksums. Post-processing steps may also be used to introduce or modify forensic watermarks, for example, to allow for traceable copying to a particular device. The decoded/processed data may also be executed using an interpreter, allowing portions of the decryption/playback code itself to be distributed in encrypted form and allowing the content to take advantage of a wide variety of code hiding and obfuscation techniques, such as using self-modifying code. It is even possible to construct multifunctional data, e.g. data that when executed performs useful tasks but also represents valid compressed video.

When processing is complete and the output data is ready, the content code may invoke additional procedure calls (e.g., DLX "trap" operations) in the player to output the data to the user. The call may, for example, communicate data to one or more video decoders (e.g., MPEG-2 decoders), audio decoders (e.g., MP3 or AC-3 decoders), or graphics overlay systems (e.g., with transparency/overlay capabilities and support still image and/or animation engines such as GL, ShockWave, or Flash). If appropriate, the data will be converted (e.g., decompressed) and then rendered. Presentation may comprise communicating data to one or more physically separate devices, such as audio speakers or video displays.

An advantage of an embodiment that uses decryption and decompression/output as separate API calls is that it allows greater control of the content, but has the potential disadvantage of increasing the number of times the content needs to be read from and written to memory. In practice, however, random access memory is typically sufficiently fast that the additional latency is controllable even for very high bit rate content such as high definition video with cinema playback quality. On high speed implementations, the player codec may not be needed because decompression may be implemented in interpreted code. The player may also provide single instruction multiple data parallel processing capabilities (e.g., by providing single instruction multiple data mathematical operations accessible via procedure calls substantially similar to MMX, SSE, and SSE2 instructions on an x86 processor) to improve performance of codecs, graphics processing operations, and so forth, implemented using interpreted code.

Various interpreters may be used to enforce the policies. In one embodiment, the interpreter is implemented in software running on a general microprocessor. In another embodiment, the interpreter is implemented using reconfigurable logic such as a field programmable gate array. In another embodiment, a dedicated hardware device fulfills the role of an interpreter. In all three cases, the procedure call may be implemented using any combination of (without limitation) native software, hardware acceleration, and calls to external devices or components.

Native code

In addition to interpreting player-independent sandboxed code, the player may also allow the content to submit native code for execution and/or storage. The player authenticates the code before accepting software or logic that can access the key or other privileged resource. Verification may be performed, for example, by determining that the code includes a valid RSA digital signature issued by the player manufacturer or another trusted party. The successfully verified native code may be stored in volatile memory for execution by the currently loaded content, or it may be stored in the player's non-volatile memory, where it may be utilized by other subjects. For example, to avoid possible negative effects on other topics, patches may be stored in volatile memory that are used only by the currently loaded topic to correct decorations (cosmetic quick) in the player or to provide performance optimization. Instead, upgrades for correcting security vulnerabilities will typically be permanently stored in the player's non-volatile memory.

Native code is typically specific to a single player platform or player application, making it less portable than interpreted code. This has the advantage that interpreted code can be used when the need arises that it cannot handle using it. For example, the native code may be used by the content as a way to distinguish legitimate players from unauthorized emulators or "duplicates," thereby avoiding the need to revoke each potentially affected device each time an attacker discovers a serious security weakness in the design of the product. As a defense against such attacks, product vendors may include built-in native code capabilities or interpreter operations that are difficult to emulate or reverse engineer. It should be noted that the ability to be designed to help detect or respond to attacks on a particular player may be vendor-specific and/or player-specific, as it will only be activated in response to a problem with a particular player. Specific measures may include (without limitation): simple non-record features, timing sensitive routines, operations that are explicitly designed to be difficult to reverse engineer or simulate at full software speed (see, for example, Kocher et al, U.S. patent No. 6,289,455 pseudosymmetricfunction, which is incorporated herein by reference in its entirety), and full cryptographic enablers (symmetric or asymmetric). In the case of a device in which the interpreter is implemented in dedicated hardware, the "native" code and the interpreted code may be similar or identical (although they may operate with different privileges, in which case the player may restrict execution at higher privilege levels to specially authenticated code).

In an exemplary embodiment of content using native code, the media includes an initial bootstrap section comprised of interpretive code that loads additional interpretable code when interpreted. The content code (e.g., code loaded by the boot program portion) will then issue a procedure call to the player and analyze the results to determine information about the playback environment, including the player type. The content may also verify the playback environment, for example, by requiring the player (or other component) to perform cryptographic operations using a key that is specific to (or characteristic of) the reported playback environment characteristic. To prevent a malicious interpreter from tampering with the verification result, the result of the operation can be used in subsequent decoding and replay processes. (e.g., by incorporating cryptographic results from the player into the decryption key calculation, the content may be securely prevented from playback on a malicious player who claims to have certain player type or playback environment attributes but lacks the corresponding cryptographic key; the results may also be compared to expected values, checked using a public key scheme, etc..) the content then determines whether the player is of a type that (by default) includes a security flaw (or other problem) that needs to be corrected. In making this determination, the content code may analyze information from within the player (e.g., data in non-volatile memory accessible by the content, date/time information from a clock in the player, etc.) and/or information obtained externally (e.g., by querying an attached device or communicating via a network). If a problem is identified, a corresponding countermeasure is retrieved (e.g., from media or via a data network such as the Internet). Depending on the nature of the problem, countermeasures may involve interpreted code and/or native code. In the event that native code countermeasures are necessary, the content may submit the countermeasure code to the player as digitally signed data, including instructions indicating whether the code should be cached in volatile memory for future use (e.g., via procedure calls), whether it should be stored permanently (e.g., to correct program errors in existing non-volatile memory), and/or whether it should be executed immediately. The native code may also be configured to perform identifiable operations (such as cryptographic calculations that may be combined with the content decryption process) so that the content code may determine that the native code was indeed executed by the player. The native code may also be configured to disable a malicious player, such as by rewriting keys. The content may also query, analyze and pass code and code updates (local or interpreted) to other devices such as a display or speaker connected via a digital interface. Once the playback environment is acceptable, the content code continues playback at the user's request, for example, by loading blocks of data from the media, performing decryption operations while forensic watermarks are inserted, and passing the decrypted data for decompression and output.

Standardization and performance considerations

It is often desirable to have standards that define the playback environment in sufficient detail so that manufacturers of compatible players can be confident that their products will be able to play compatible content (subject to security policies, etc.). The standard will typically specify the basic instruction set (or equivalent) of the interpreter and the required procedure calls. It may also be desirable to define performance requirements for any instructions and procedure calls that may be included in the real-time portion of the decoding process. (for operations that are performed only during startup, shutdown, and other non-real-time operations, performance requirements are typically less critical.)

For example, one exemplary specification may require that a compatible interpreter be capable of performing a minimum of eight million "time units" (TUs) per second, where normal low-level interpreter operations may each take up to one TU, and multiply and divide operations may each take up to 4 TUs. The performance requirements for the invocation of player-provided processes (e.g., DLX "trap") depend on the requested operation. For example, an AES encryption operation may take up to 100TU plus 12TU per block cipher calculation. Word-aligned memory replication may take up to 50TU plus 1TU every 16 bytes (or fraction thereof). The completion status of buffering one media read request or checking buffered requests may take up to 100 TU. The read requests are executed one at a time in the order of submission but in parallel with other processing, and may occupy up to 10,000 TUs plus 1500 TUs per 2048-byte sector. Non-sequential reading may take an additional (20000+640000 × seek distance in sectors/maximum number of sectors per media) TUs for seek overhead. Loading data from a completed read (i.e., transferring data from the drive's buffer to the interpreter's memory space) can take up to 100TU plus 128TU per 2048-byte sector transferred. Transmitting data to a codec or other output may take up to 100TU plus 1TU of 16 bytes (or fractions thereof) per transmission. Of course, these timing values are provided for exemplary purposes; the specific performance index will depend on the requirements of the system. More complex performance requirements (e.g., specifying the total computation time of the instruction sequence) may also be specified to provide greater flexibility for player implementers or better performance guarantees for content authors.

In practice, many implementations will run much faster than the lowest performance values. This simply means that the data will be ready before it is needed. For example, a software-based interpreter that takes 40 clock cycles per conventional interpreted instruction would exhibit a processing speed of about 50 million TU/sec on a 2GHz microprocessor. Similarly, a dedicated hardware implementation running at a frequency of 25MHz and 2 clock cycles per instruction would also be much faster than 8 million TUs per second.

It should be noted that standard developers face a balance between simplicity and performance of the system. In particular, for software-based implementations, it can generally be assumed that operations performed in procedure calls run much faster than the same operations in interpreted code. On the other hand, these operations must typically be defined in advance and typically also include entry/exit overhead in their performance assumptions. However, procedure calls for common operations such as memory copy, search, large number arithmetic, and cryptographic computations can provide significant performance benefits. An alternative performance enhancement approach is for the interpreter to analyze the content code to identify areas that can be optimized (e.g., translated into native code) before or during execution. The content code may also include a "hint" to inform the interpreter of the candidate regions that are suitable for optimization. The benefit of the "hint" approach is that hardware implementations (which tend to be faster, but more difficult to perform complex operations) can ignore hints (e.g., by treating them as NOPs) and process subsequent code normally. Software implementations (which tend to be slower but have higher speed native code capabilities) may use hints to replace interpreted code with functionally compatible native code routines. The performance standard may specify commonly constructed player performance requirements, if desired. The player may also allow the content to select between an interpreter mode that always guarantees that the lowest value of performance is met (e.g., for real-time tasks) and a mode with better average-case performance (e.g., for non-real-time tasks).

When editing content, the content developer needs to verify that the software it has written meets the performance minimum specified by the standard. A specialized test system for verifying timing compliance tabulates worst-case performance characteristics (tabs) of the content code as it executes. It operates by emulating the playback process while tabulating the maximum allowed time that the player can take to perform each sub-operation. If the playback process is too slow (e.g., if the measured worst case player performance lags the time stamp in the data provided to the codec, or if the codec becomes out of data), the tool may notify the media author, who may then correct the problem. The editing tool may use the same method to ensure that its output will play reliably.

Protecting non-volatile memory

As described previously, the player device may provide non-volatile (NV) storage capability for content to be used by the content. Because the number of entities writing content may be large (possibly including small artists, students, home users, etc., as well as large studios), it may be advantageous for content and players to enforce restrictions on NV memory usage given that some content may be written loosely or even maliciously. Thus, the player may wish to limit the ability of each theme to save NV memory and read, modify and overwrite stored data. A section entitled "secure memory and counters" describes the use of digital signatures to verify code that accesses non-volatile memory. However, in certain situations, it may be desirable (e.g., for political and/or technical reasons) for the non-volatile memory security mechanisms to operate without a centralized authentication authority while still allowing the content theme to configure and/or control the non-volatile memory regions.

The following section describes an exemplary embodiment of a player that provides secure access to non-volatile memory for content without requiring a centralized signing authority. Referring to FIG. 4, an exemplary memory manager controls access to 128 kilobyte flash that is divided into 511 slots (slots) of 256 bytes each and 256 bytes for additional data. Each slot after slot 0[410], slot 1[412], slot 2[414], and slave 440 includes: a 128-bit author media ID 420 that identifies the media ID of the subject that was originally assigned to the slot; the 128-bit last updated media ID 422 that identifies the media ID that most recently modified the subject of the slot; a 40-bit last update sequence counter 424 that identifies when the slot was most recently updated; if the slot needs to be overwritten with an 8-bit slot priority value 426 indicating the level of the slot; 16 bytes of private data 428 that is accessible only by authorized code; a 160-bit hash value 430 of the code authorized to access the slot; and primary slot payload data 432. When the player is initialized at the factory, these values may all be initialized to zero to indicate that the slot is empty.

The last 256 bytes of the 128 kilobyte nonvolatile memory are used to store values including: secret player key 444; a counter 445 containing the number of priority 6 slots that have been overwritten; a counter 446 containing the number of priority 7 slots that have been overwritten; and slot write counters stored as high 447 and low 448 portions. Because the slot write counter is updated frequently and some non-volatile memory technologies wear out after excessive write cycles, this counter is stored in a manner that limits the number of times any particular memory cell is updated. The counter is incremented by setting the bits in the low portion 448 unless 1023 of the 1024 bits in the low portion are full, in which case the high portion 447 is incremented and all 1024 bits of the low portion 448 are cleared. The counter value is read by multiplying the high portion 447 by 1024 plus the number of bits set in the low portion 449. When the player is initialized at the factory, these values may all be initialized to zero, except that the player key should be initialized to a secret (pseudo) random value.

The player also maintains a number of values that can be stored in volatile memory (e.g., conventional RAM). These values include the media key 450, the media identifier 452, a value 456 indicating which slot is currently attached (i.e., from the number 0 to 510), and a value indicating the highest priority slot written by the current theme so far in NV memory. When the theme is initialized (e.g., when media is inserted or the player is reset), the attached slot identifier 454, the attached slot priority 456, and the maximum authoring priority 458 are reset. The media key 450 is preferably loaded from a portion of the media that is not writable on the consumer recordable media by the consumer recordable device. The media identifier is then derived 452 from the media key by applying a one-way cryptographic transformation such as the secure hash algorithm (SHA-1) as is well known in the art. To provide additional assurance, the media may carry a cryptographic signature that authenticates the media key 450 and/or media identifier 452, which may then be authenticated by the player and/or content code. Alternative embodiments may include other values (such as the identity of the facility that manufactured or embossed the media and/or an identifier that is specific to a particular segment of the media) and do not necessarily have a fixed relationship between the identifier and the key.

In general, the content code may be allowed to have fairly unlimited read access to the non-volatile memory contents, except for the private data 428 of each slot. This read access may be implemented using a procedure call (e.g., a DLX "trap" operation) that allows the content to specify the slot number and retrieve the content. If the requested slot is not currently attached (i.e., identified by the attached slot identifier 454), then no slot private data 428 is returned (e.g., zero is returned for these locations).

In an exemplary embodiment, the content is provided with the following basic operations to read from, request access to ("attach") and modify the non-volatile memory slot:

slot read (SlotRead): this procedure call reads the contents of the specified slot into a memory space accessible by the content code. The input parameters to this process include the slot number and a pointer indicating where in the memory of the content the result is stored. The entire slot contents are returned (which are typically set to zero in the read result, except for private data field 428). If the specified slot number is (-1), then the slot identified by the attached slot identifier 454 is read and the entire content (including private data 428) is retrieved and stored. The return value of the operation is an integer that contains either the number of the slot read (e.g., the attached slot identifier 454 if slot (-1) is specified) or an error code indicating why the request failed.

Slot attach (slottach): this procedure call is used to request privileged access to a specified slot. Before granting this access, the code making the request is authenticated. The input parameters to the process identify the slot number, code length, and requested priority level. The process determines the starting address of the code (e.g., the address in the memory of the content after the instruction that called the slot attach operation) for which access is to be granted. Using the address and the specified length, the process then calculates a cryptographic hash value of the code (e.g., using SHA-1). If the hash result does not match the value of the authorization hash 430 stored in the slot or if the requested priority is determined to be invalid (e.g., as described below with respect to FIG. 5), then slot zero is attached (i.e., attached slot identifier 454 and attached slot priority 456 are set to zero) and an error message is returned. Otherwise, the requested slot number becomes the currently attached slot (i.e., the attached slot identifier 454 is set to the requested slot number and the attached slot priority 456 is set). As a special case, the calling code may specify a slot number of (-1) to request the configuration of a new slot. In this case, the player verifies the requested priority (e.g., as described below with respect to fig. 5) and returns an error message if the priority is invalid. Otherwise, the player selects one slot to overwrite (as described below), clears it (e.g., by setting the author media ID 420 to the current media ID 452, zeroing out the other slot fields, and incrementing the write counter 447/448), attaches to that slot (e.g., by setting the attached slot identifier 454 to the slot number and the priority 456 to the requested priority), and sets the maximum authoring priority 458 to the greater of its current value and the requested priority 456. If the interpreter supports interrupts or other capabilities that may cause the unexpected execution of potentially untrusted code, then these capabilities should be disabled to avoid the introduction of malicious code while the slot is attached. The return value is the attached slot number 454 or, if the operation fails, an error code (e.g., due to a requested priority of code hash value not matching or being invalid).

Slot write (SlotWrite): this procedure calls for writing data to the currently attached slot. The input parameters to this process point to the new contents of the slot private data 428, authentication hash 430, and payload 432, which are written with the updated values of the other slot fields. (specifically, author media ID 420 is unchanged, last update media ID 422 is set to current media ID 452, last update sequence counter 424 is set to slot write counter 447/448, and slot priority 426 is set to attached slot priority 456.) Prior to a slot write, the slot write counter is incremented by updating the low 448 and, if necessary, the high 447 portions of the slot write counter. Players that use non-volatile memory with a limited lifetime (e.g., many flash and EEPROM memories rated for one million write cycles) may refuse to write if too many (e.g., more than 128) writes have been performed since power up/media insertion. The write operation resets both the attached slot identifier 454 and the attached slot priority 456 to zero. The return value is a status code indicating whether the write was successful.

Providing slot priority management support to balance several potentially conflicting goals, including: (a) the content should be able to access as much non-volatile memory as it reasonably needs; (b) the content should be sure that its non-volatile memory is not accidentally overwritten; (c) a theme should not be able to reserve excess non-volatile memory and thereby prevent other themes from reserving any non-volatile memory; (d) if there are no empty slots available in the non-volatile memory, the rarely used slots should be recycled to provide some non-volatile storage space for the new content; and (e) a topic should not be able to submit large numbers of requests intended to have legitimate slots recycled. In general, if the player's slots run out, the slots with higher priority are less prone to be overwritten. In an exemplary embodiment, the priority rules are designed to ensure that each media theme can have at most one highest priority slot (priority 7). In addition, media is only allowed to create one slot with a priority of 2 or higher during each insertion or player power-down reboot (power cycle). Although the slots reserved when the player is manufactured may have a priority level higher than 7, the content cannot create slots with a priority higher than 7.

FIG. 5 illustrates an exemplary process for verifying whether the priority requested for the attached slot is acceptable. When a slot is attached or created (see the "slot attach" section above), the content specifies the requested priority value. At step 500, the player checks whether a new slot is assigned (e.g., slot number specified as-1). If so, at step 510, the player checks whether the requested priority exceeds the existing priority 426 of the slot, and if so, the player returns an error message indicating that the requested priority is too great. Otherwise, at step 520, the attach request is allowed to continue with the requested priority. If step 500 concludes that the request is to allocate a new slot, then at step 530 the player checks if the requested priority is equal to or less than 7, and if not, returns an error message. Otherwise, at step 540, the player checks whether the requested priority exceeds 2, and if not, accepts the requested priority as valid for the allocated slot. Otherwise, at step 550, the player checks the maximum creation priority 458 to determine if any slots with a priority greater than 2 have been created since the media insertion or player reset, and if so, rejects the requested priority. Otherwise, at step 560, the player checks if the requested priority is 7, and if not, accepts the requested priority as valid for the allocated slot. Otherwise, at step 570, the player checks whether there is already a slot with priority 7 whose stored author media ID 420 is equal to the current media ID 452, and if so, the player rejects the requested priority as invalid. Otherwise, the requested priority is accepted to allocate the slot.

When a new slot is allocated (i.e., the content calls slot attach with slot-1 (slottach)), the player selects the slot with the lowest priority 426 for overwriting. At the factory, the empty slot is initialized with the lowest possible priority (zero) and therefore will typically be used first. If multiple slots share the lowest priority, the slot with the lowest write sequence counter value is selected. If a slot with priority 6 or 7 is selected for overwriting, the corresponding counter (priority 6 overwrite count 445 or priority 7 overwrite count 446) is incremented. Alternatively, a player with space for a large number of slots may simply fail if the request would require or otherwise involve rewriting the high priority slot.

At the factory, certain slots may be initialized with a predetermined value and non-zero slot priority for the authentication hash 432. The functionality and/or security requirements of the slot depend on the hashed code. For example, the code for determining a predetermined authentication hash may be configured to perform the steps of: (a) initialize all registers (e.g., stack pointers, etc.) to a "safe" value; (b) loading an RSA signature value from a predetermined address outside the authenticated code region; (c) determining whether the RSA signature is a valid signature of a region of the memory of the interpreter using a public key embedded in the region identified by the slot attach operation; and (d) if the RSA signature is invalid, detaching from the current slot (e.g., by attaching to commonly accessible slot 0), otherwise jumping to the first address of the digitally signed region. If only digitally signed code is desired to be played on a particular player, the code may be configured, for example, to check the identity (or other attribute) of the player and/or to decrypt a portion of the code before running it using the player key.

The example in the preceding paragraph illustrates a method for implementing asymmetric signature verification using a hash-based slot verification scheme (e.g., as described in the section entitled "secure memory and counters"). This method allows slots to be reserved for future use, which need not be specified when the player is manufactured or standards are defined. It is also possible to sign code implementing a hash-based approach using a public-key based code verification system.

It is possible to use a single slot for multiple purposes. For example, multiple code fragments may be digitally signed to pass a verification process such as described above. Each of these code fragments may be configured to modify different portions of the slot and to separate appropriately when completed.

It is also worth noting that the private data field 428 of the slot enables the code to encrypt the slot contents. While anything can read the primary slot payload, only authorized code (e.g., using the slot attach process) can read the private data 428. The authorized code may thus use the private data 428 as a key (or derive a key) to encrypt and decrypt the slot contents. In this way, the privacy of the data stored in the slot may be ensured. The content also has the ability to attach an authentication code or digital signature to the slot content if desired. The signature may be generated by the content code (optionally using a player key), may be generated by the player, or may be generated by an external party or device, such as the publisher of the subject matter or the manufacturer of the player. The subsequent subject matter may then be configured to search through all slots for digitally signed (or otherwise authenticated) values indicating, for example, that certain security checks are necessary or that a particular media ID has been revoked.

Slot-based features may be shared by multiple themes. For example, a date manager may be implemented that provides the latest known date for the content. Each topic using this capability will carry a digitally signed representation of the current date when it was produced and a number of predetermined codes that match the authentication hash 430 of the slot. The code for managing the slots will: (a) checking the digital signature of the date carried by the content and, if invalid, detaching from the slot and stopping; (b) reading the content of the current slot; (c) compare the date of the now-verified from the subject with the date in the payload 432 of the slot; (d) if the date of the theme is later, then place the date of the theme in the slot contents and invoke a slot write to store the new date in non-volatile memory while keeping the remainder of the slot unchanged; (e) separating from the slot; and (f) erasing the slot private data (and any other unimportant values) from the RAM. The operation will return an error message or the later date value (i.e., the later of the authenticated date carried by the subject and the date previously stored in the slot). The code may optionally store a digital signature with a date so that corrupted dates are not misinterpreted as being in the distant future. In addition, the date may also be stored encrypted (e.g., using the value of the private data field 428 as a key) to limit read access to the stored data value to the subject including the current date. The date value in the player may be used, for example, by the content to determine if a security update is needed, if it is time to perform an online security check, if it is time to submit a pay-per-view purchase record, etc.

In some embodiments (e.g., embodiments that provide real-time network capabilities), it may be advantageous to have the player limit access to non-volatile memory when network support is enabled. This restriction may help ensure the privacy of the user, for example, by preventing malicious content from fetching data from non-volatile memory and transmitting it over the network. As a particular example, topics that use network access capabilities may be prevented from reading data from slots (or reading certain slots, such as those that may contain user identification information or be created by other topics). The player may also allow the theme to terminate its network access privileges and gain broader slot access (e.g., obtain values for forensic watermarks once network access is no longer needed). It should be noted that the information embedded in the forensic watermark does not raise the same privacy concerns, as this data can only be recovered from the copy of the content.

The above description of specific non-volatile memory management is intended to illustrate a particular embodiment. Of course, many variations are possible. For example, specific slot configurations, slot management operations, and priority management methods are provided for illustrative purposes. In addition to configuring memory as fixed-size slots, other memory management methods may be used (including using non-slot-based configuration methods). Other access control mechanisms (such as mechanisms that are not based on media identifiers) may also be used. The total amount of non-volatile memory for a slot may be variable (or virtually unlimited, as in the case of a hard disk or other high capacity storage technology). A separate non-volatile storage capability may be included to track media/disc insertion history. It may be advantageous to use cryptography to encrypt and/or authenticate the contents of a non-volatile memory (or other memory such as memory accessible by the contents) to prevent unauthorized reading/modification. In a software implementation, a variety of code, address, data, and algorithmic obfuscation techniques may be used to prevent the player key from being extracted (or tampered with). Any form of data may also be stored in the slot, including (without limitation): pay-per-view purchase records, counters of any kind (e.g., purchase counters, credit/debit or other balance counters, failure counters, media/disc insertion counters, etc.), results of online or phone-based security checks, viewing records/history, codes (interpretable or local), revocation data (for players, peripherals, etc.), signals to other topics, information for assessing eligibility for rebates or discounts, transaction and playback history data, digital signatures, and keys.

Media revocation

One notable scenario is where the player is trusted but the media has been stolen. This is typically the case for professional pirates, as they will generally seek to provide "products" that are as close as possible to legitimate copies. All off-line media playback devices are potentially vulnerable to such attacks if a pirate develops a method for producing copies of legitimate media that the player cannot be physically distinguished from the original media. Media characteristics that are difficult to replicate, such as measurements of the wobble characteristics of tracks on an optical disc, can be used to make accurate replication more difficult, but a firm pirate can still find a way to make copies. Similarly, forensic watermarking allows content owners to identify devices used to pirate previous content, but does not prevent the playback of pirated content.

To cope with the risk of pirates making unauthorized copies of the media, the content owner can set a unique identifier for each copy on legitimate media. For optical discs, this data may be placed in an area that can be written uniquely in the factory (such as a burst cutting area on some existing stamped optical discs) or on a recordable optical disc (e.g., using storage technologies such as those currently used to manufacture recordable CDs and DVDs, magneto-optical discs, etc.). Uniquely writable regions need only carry a small amount of information (e.g., a few bytes to a few hundred bytes). Specifically, this area may carry recorded serial numbers, user information (name, phone number, etc.), cryptographic keys, etc., as well as digital signatures to authenticate these values. For consumer recordable media, a unique media serial number (and optionally an associated digital certificate) may be recorded for each blank media piece manufactured.

The content code on the media may be configured such that when the media is inserted for playback, the authenticity of its unique data is verified. Depending on the media type and the recorded data, this verification process typically includes verifying a digital signature that is unique to a piece of media. To prevent adversaries from circumventing this verification check, verification may be performed using obfuscated code, the check may be performed multiple times (e.g., at different times during playback) and the verification results may be combined with subsequent decryption processes. If the unique data is not valid, the content code will typically refuse playback. Otherwise, the content code can be confident that either (a) the media is legitimate, or (b) it is copied from a piece of legitimate media having the unique data.

Next, to determine whether the unique media is valid or revoked, the content checks a data field in a non-volatile memory area of the player that indicates the revocation status of the currently inserted media. If no matching revocation information is found, the media is assumed to be valid. To prevent inadvertent or malicious revocation, the revocation data may be authenticated by checking a digital signature or other authentication data (such as a pre-map of cryptographic hashes). The data in the player's non-volatile memory may also indicate which, if any, actions are recommended, such as (a) notifying the user that the copy is illegal, (b) allowing playback at a reduced resolution, (c) preventing playback altogether, or (d) allowing the user to legally purchase content (e.g., by dialing a telephone number and entering an unlock code, or by interacting with a server via the internet). The non-volatile memory may also override the (over-ride) previous revocation message, e.g., so that the content may be "un-revoked" if desired. If there are multiple conflicting status indicators, the sequence number or date may be used to determine which is the most recent.

In some situations, it may be useful to create media that can only be played on specifically authorized devices, such as pre-registered devices. In this case, rather than providing revocation, unique media information may be used to enable media activation. For example, a copy of the preview (advance review) and a copy of the trial are generally not required (and should not) be playable on all players. The data recorded in the writeable section may include a decryption key or other information specific to the authorized recipient of each piece of media. The area of unique record may also include a name, e-mail address, account number, or other data identifying the particular recipient (e.g., for forensic watermarking purposes, interactive features, etc.) or characteristics of the recipient (e.g., viewing preferences, authorization data, group identifier, zip code, etc.). These fields may also be written during or after the sale of the media, for example, as an activation step to prevent media stolen from the store from being played (thereby reducing the risk of shoplifting the store that displays the media on its shelf). The backend system may compensate the merchant for media that has not been activated or charge the merchant for media when the media is activated. Another use of this capability is to distribute "locked" media before the official release date, then write the playback-enabled key on the writable area when playback is authorized. The information may be recorded by an entity or facility other than the media producer, such as a retail facility, a transportation facility, or a security agency (e.g., if the pressing facility is not fully trusted). If portions of the media are writable by the end user's device, it is also possible to record data (such as authorization keys, player identifiers, etc.) when the media is played or unlocked. The writeable portion on the media may be used, for example, to implement features such as "canned" material that can be unlocked for a fee and then played on multiple players.

For offline players, the revocation notification will typically be delivered on a subsequent theme. For example, the new theme may carry a list of serial numbers (with accompanying authentication data) that identify the revoked media. If the player has sufficient non-volatile storage space (e.g., a hard disk), the entire revocation list may be stored by the player. Otherwise, the revocation data may be checked against the insertion history of the player and/or the non-volatile memory slot to determine if there is any media that has been played by the player that is revoked. If so, the corresponding revocation data is stored in the non-volatile memory of the player. In this way, a pirated "cloned" media will be playable when it is first inserted, but will be revoked (or otherwise "marked out") after a piece of media that revokes the pirated media is inserted. Media revocation is generally valuable because it makes pirated media less attractive to consumers than legitimate media.

Media activation/revocation may be used to implement a variety of promotional and security features. For example, a movie may be sold with multiple media containing different versions (e.g., wide screen, pan-scan, director's cut, etc.). To prevent someone from selling or renting the media separately, their content code may verify that one or more other media are being presented in the player's non-volatile memory. Optionally, other media may also be required to have been inserted recently (e.g., within a certain time or a certain number of increments of the slot write counter 447/448). Alternatively, the media may also require the user to insert another piece of media during playback (e.g., by loading a key value from the other media). A promotional mode may be established in which the user will have access to the collateral material if the user has played some combination of other content. Of course, the playback decision is also linked to other information, such as the characteristics of the player and/or the playback environment.

Players with online capabilities may check the revocation status of currently inserted themes as well as other themes represented in the player's media insertion history and/or non-volatile memory slots. This check may be implemented in the content code or may be performed by the player. Online checking can also be used to detect situations where multiple players are playing a single piece of media at the same time (e.g., indicating that the media has been pirated) or where an excessive number of players have used a particular piece of media (e.g., indicating that they have been rented in violation of a license agreement).

Pirates may try to circumvent revocation checking by modifying the code of the content. In this case, subsequent portions of code (e.g., code executed later during playback) may detect the modification, for example, by repeating the check or by reloading and verifying the portion of the media that includes the authentication code. Revocation checking results may also be combined with the decryption process.

Of course, variations of the media revocation method may be used. For example, the player may store digitally signed, interpreted code configured to identify revoked media. These code segments (snippets) may be executed each time media is inserted to determine if the newly inserted subject is revoked. The theme will be able to store revocation check code (preferably with a corresponding digital signature to be verified by the player) which the player will retain for checking future media. The media revocation check may also be performed by code in the ROM of the player, for example, by storing a table of sector numbers and hash values for revoked optical discs in the player's non-volatile memory. If the media is writable, the content may also store and retrieve revocation data on the media itself (or may store any other kind and purpose of data on the media, such as user preferences, user information, etc.).

The medium may also be used to carry revocation data regarding the recording device. For example, if a consumer recording device is configured to place identification data on its record, the player device may maintain a record of the revoked recorder. These records may be updated by revocation data carried on the media. Recordable media may also be manufactured with information identifying a revoked recorder to prevent the revoked recorder from writing to the media. The revocation-related data fields may be cryptographically authenticated, for example, to prevent malicious or inadvertent revocation of legitimate devices. For example, the identification data set by the recording device may include a recorder digital certificate and a digital signature on a media serial number. The identification data provided on the recordable medium may be encrypted (e.g., using a public key of a third party agency) to protect the privacy of the user. Threshold cryptography (e.g., to require multiple media to identify a recording device) may also be used. (Note that threshold cryptography may also be used with other aspects of the techniques disclosed herein, such as with forensic marks to ensure that a certain amount of copied material is required to recover the mark.)

Another use of media revocation is to provide an additional deterrent against accidental piracy, in addition to other methods available. Data embedded in the forensic watermark may identify previous media played by a device. Depending on implementation choices, it may be advantageous to revoke other media whose ID is determined from the forensic watermark of the pirated copy, revoke recordable media whose serial number is close to the media used to distribute the pirated material, require additional authorization steps before playback from the media in question, and so forth.

Miscellaneous features and capabilities

Security override Key (Security Over-Ride Key):the content may be designed such that a player with knowledge of the security overlay key may circumvent some or all security checks, allowing access to some or all of the content. By supporting the key, the content owner may grant access to a restricted portion of the work (e.g., if one region requires the content owner to grant a critic access to the video on a frame-by-frame "fair use" basis). These overlay keys may also be used to "free" content from its protected form, for example, if the protection features are not well designed (causing playability issues). These keys may be kept by a third party (or stored on media encrypted with the public key of the third party) if desired. The overlay key may also be predetermined to be released upon expiration of the copyright, for example, to address issues that an anti-piracy mechanism may prevent content from entering the public domain.

Multiple Round Collusion Analysis (Multiple Round volume Analysis):in some cases, a firm pirate may combine the outputs from a large number of devices in an attempt to prevent recovery of the forensic watermark. If a pirate has compromised so many devices that the content cannot directly identify the rogue device, it is possible to combine forensic information gathered from multiple content versions. For example, information gathered from the first topic may narrow the range of devices that may be used by a pirate, but not uniquely identify all rogue devices. This knowledge can be used when making the second subject matter to create a forensic watermark that will provide further information about the attacker and/or his device. This process may be repeated until the pirate has been uniquely identified.

Counter measures to malicious interpreters:it is possible to design a malicious player to try to spot the contentSecurity-related code. For example, a malicious player may attempt to identify where the content performs RSA signature verification operations and modify the results, e.g., making invalid RSA signatures appear valid. If the player is made, the content owner can edit the new content to use a different RSA signature calculation routine designed to circumvent this identification. Examples of operations that may be used include (without limitation): rewriting code to avoid unreliable operation; obfuscating the code; message blocking; examining the trial computation results to detect an attack; and combining the intermediate values and/or results with other cryptographic operations, such as a decryption step.

Interactivity:the virtual machine/interpreter may be used for non-secure tasks as well as for secure purposes. For example, the content code may be used to display menus, text, graphics, animations, user interface elements, and the like to the user. Similarly, content may receive user commands or responses including (without limitation) mouse input (e.g., move, click), buttons (such as keyboard or remote control input), light pen input, and joystick actions. Information about the native player (such as camera input, microphone input, changes in user body position, etc.) may also be gathered and used, for example, to control playback. The player may also provide features to facilitate user interface implementations including (without limitation) the ability to display dialog boxes, manage display windows, perform speech recognition, manage user preferences, and the like. As a deterrent to piracy, code implementing interactive user features may be combined with security code so that pirates cannot easily distinguish them.

Accessing and exchanging content via a network

While most consumer video and audio content is currently distributed on optical media, the popularity of streaming downloads is expected to increase. The security measures provided herein may be redesigned to support streaming content or locally cached content instead of or in addition to physical media. Instead of loading the data from media actually located at the player, the content code and data are retrieved via a network. For example, instead of issuing a procedure call requesting a sector of data from media, the content would issue a procedure call requesting data via the network. Unlike passive media, the remote server itself may have processing capabilities, such as allowing it to send requests to the content (e.g., to cause the player to perform cryptographic operations) and verify the results. Security protocols (including without limitation, SSL) for protecting data exchanged over a network may be implemented in the code or player (or other component) of the content.

A simple server implementation would receive incoming requests from authenticated users (e.g., users who have paid for access to content), read the corresponding data from their own local storage, and communicate the results. More sophisticated servers may select and/or modify data in real-time, for example, to embed forensic watermarks, and may interact with other servers. The server may also store information about or on behalf of the remote player (e.g., as a replacement for player-based non-volatile memory), deliver security code customized for the end user, perform real-time revocation checks, automatically insert security upgrades into content, provide internet/network proxy capabilities, and provide other services to the content code. For example, an exemplary transaction includes the steps of: (a) the content server receiving a purchase request from the end user's player; (b) the content server verifies the payment; (c) the content server transmitting a portion of interpretable code configured to analyze the functional characteristics and/or security characteristics of the user's player; (d) the user's player runs the interpreted code and returns information about its characteristics; (e) the content server analyzes the response and transmits security check logic (which includes interpreted code and/or native code and can be custom generated) to the user's player; (f) the user's player processes the verification logic and returns a response to the server; (g) the server verifies the response; (h) the content server transmits (e.g., streams) encrypted digital content (e.g., audio, video, and/or images) to the user's player; and (i) the user's player decrypts the content (correct operation of the decryption process may require the correct key or results from the security check logic).

The server process itself may be controlled by interpreted code, optionally using the same interpreter structure (e.g., DLX) as the player side. This has the advantage that the content can be edited without regard to the physical hardware structure of the server. This is a particularly attractive mode for a home network environment, as the server maintains security and decoding "intelligence" while the content can be continuously broadcast out to authenticated local devices. Similarly, for content to be continuously broadcast via a variety of different internet services, a server-side interpreter may allow the content to be edited once and continuously broadcast from any compatible service.

In some cases, the recipient device may also possess the ability to make its own security decisions, such as in the case where the receiving device wishes to cache the content and later transmit it to a subsequent device whose identity is unknown during the initial transfer. In this case, the initial transmission may include interpretable code and/or locally executable code used by the recipient device to make its security-related decisions. Since the code executed by the transmitting device is not necessarily the same as the code executed by the receiving device, it is not necessary that all devices support the same interpreter or programmable technique.

In some cases, multiple servers and/or content delivery may be involved. For example, the content may include security codes obtained from multiple entities, including, for example, servers operated by the player manufacturer and content owner. In some personal computer environments, it may also be useful to use multiple interpreters. For example, the interpreter may be included in a media interface (e.g., optical disk drive), an operating system, application software (e.g., player), an output device (e.g., amplifier), and so forth. Alternatively or additionally, a password affordance may also be provided in the assembly.

Player operation calling and marking method

The player device provides an interpreter (typically implemented in software) that allows the content code to perform a variety of individual operations. The operations include manipulating virtual registers and accessing memory belonging to content code. In addition, the content code may also call TRAP (external operation implemented in the player). TRAP may be used to perform operations that content code cannot directly perform by manipulating its own resources (such as accessing peripheral devices), or to provide higher performance than could otherwise be guaranteed by content code.

The notation used for this section is designed to be familiar to C/C + + programmers. The types UINT8, UINT32, and UINT 64 are used to represent 8-, 32-, and 64-bit unsigned integers, respectively. In an exemplary embodiment, each prototype corresponds to a sequence of 32-bit values that should be entered onto the stack before the appropriate TRAP operation is invoked. Because all values in the stack are 32-bit in size, parameters that are less than 32-bits are extended to 32-bits, and larger values are stored using multiple 32-bit values. The actual number of 32-bit values involved in each TRAP operation may be zero (if the parameter list is empty). The number of parameters may also be variable, in which case the prototype will end up with "..". An array denoted "type name [ size ]", e.g., "UINT 32 test [16 ]" represents an array of sixteen 32-bit words. The pointer is denoted "type name", e.g. a pointer named testPtr of one or more 32-bit unsigned integers will be "UINT 32 testPtr".

The stack itself may simply be an area in memory accessible by the content code and the portion of the player implementing each TRAP. For example, an exemplary stack may be implemented by designating emulation registers accessible by content code as stack pointers. When TRAP is invoked, the value of this register is read by the content code to locate the passed parameter value. An exemplary process of pushing an integer involves first subtracting 4 from the stack pointer, then storing the value to advance to the memory address specified by the new stack pointer (if the stack pointer or stack contents are invalid, taking appropriate action such as ignoring TRAP operations or replacing valid values). Popping a value off the stack is performed by first reading the value from the memory address specified by the stack pointer, then incrementing the stack pointer by 4. After the TRAP operation, the content code and/or code implementing the TRAP clears the parameters from the stack, such as by restoring the stack pointer value. Other stacks, and more generally, function calls and parameter passing techniques are known in the background and may also be used with the present invention.

To invoke TRAP, the caller first pushes each parameter (starting with the rightmost parameter in the prototype definition), invokes the appropriate TRAP operation, and gets the return value (e.g., by reading the result value conventionally stored in register 1). For example, consider the following representation "UINT 32TRAP _ Random (UINT8 × dst, UINT32 len); "TRAP. Before invoking the trap operation, the caller (content code) will first push the 32-bit value "leh" and then the 32-bit pointer value "dst" (which is the memory address where the result should be stored). The caller will then invoke the appropriate lower level TRAP operation. Typically (although not necessarily), the content code thread that invokes the TRAP will stop while the requested operation is being performed. The return value of TRAP (represented by "UINT 32" on the left in the example prototype) is placed in a location where it can be retrieved by the content code (e.g., by placing the return value in a predetermined register). Most exemplary TRAPs return a STATUS value (e.g., a constant STATUS _ OK indicating success, or a value indicating an error condition, or a value that otherwise describes the result or STATUS of the system or operation). For the sake of brevity, if the value is only a status value, the contents of the returned value are generally omitted in the following TRAP description. Some TRAPs do not return any state values but may fail (e.g., if illegal input parameters are provided), in which case the content code may need to ensure that the appropriate input and/or verification operations are provided as expected.

The values exchanged using the TRAP operation may be cryptographically protected, for example, using encryption and/or digital signatures. For example, the value passed to the TRAP may be encrypted using the public key of the player or other device. The values may also be encrypted using symmetric cryptography, such as using a block cipher or a stream cipher. The value may also be digitally signed. Responses may also be password protected. For example, the response may be digitally signed, e.g., by the player, the manufacturer of the player, an external device, a format entity, and so forth. The particular combination of cryptographic protection (and corresponding keys, etc.) used may be specified or may be based on content code requests, player requests, external devices, the state of the player, etc. The key used to protect the data may not be included in (or accessible by) the player, such as in the case of data communications where the endpoints are content code and external devices but pass through the player.

TRAP operations often cause system states to change. For example, the register values and memory contents that the content code is visible may be changed. For example, the "TRAP _ Random" example above would store the output from the Random number generator for use by the content code. Portions of the playback system not directly controlled by the content code are also typically accessed or modified by the TRAP operation. For example, TRAP _ SlotWrite can change the contents of the player non-volatile memory slot, and TRAP _ MediaReadRequest adds one request to the queue of pending media reads. These changes may or may not be under direct monitoring of the content code.

Player operation

The following describes the TRAP operations supported by an exemplary embodiment. It should be noted that limitations, constants, and other aspects of design reflect exemplary embodiments and do not necessarily reflect other embodiments.

void TRAP_Yield(UINT32 sleepTime)；

Control of the interpreter is relinquished until the earlier of (a) a specified time in microseconds or (b) an event occurs (e.g., media read complete, etc.). Implementation does not require pausing the interpreter when TRAP Yield is invoked, however pausing the interpreter may be desirable, particularly to conserve battery power on the portable device or to conserve processor cycles on a multi-threaded system. Implementations may also choose to ignore the sleepTime parameter. This operation may take up to 1 microsecond, even if a small value is specified for sleepTime or an event occurs first. If an event occurs, control will resume within 1 microsecond after the event. If no event occurs, execution may be suspended for as much as sleepTime microseconds. TRAP does not return any information; when the player is ready, execution continues on the next instruction.

UINT32 TRAP_Random(UINT8 *dst，UINT32 len)；

Len random (or strong pseudo-random) bytes generated by the player are stored at dst.

UINT32 TRAP_Sha(UINT8 *dst，UINT8 *src，UINT32 len，UINT32 op)；

The SHA-1 algorithm is performed on the len bytes at src and the results are stored at dst. The values of Op include: SHA _ UPDATE (0) which adds more data to the existing SHA state; SHA _ INIT (1) to start a new SHA context before hashing the data; SHA _ FINAL (2) that performs an end operation when hash update is completed; and SHA _ BLOCK (3) (equivalent to setting both SHA _ INIT and SHA _ FINAL) that performs a full BLOCK operation.

There should be at least 512 bytes of space available at dst and the content of that space will be indeterminate before the end operation (e.g., op — SHA _ FINAL) occurs.

Player implementations can use 512 bytes at dst for temporary storage of state, but it should be assumed that the content of dst was maliciously selected by the content code. If successful, a STATUS _ OK is returned, otherwise one of the defined error codes is returned.

UINT32 TRAP_Aes(UINT8 *dst，UINT8 *src，UINT32 len，UINT8 *key，UINT32 opOrKeyID)；

AES ECB algorithm (as transformed below) is performed on the len block from src using the key at key and the decryption result is stored at dst. The value of the OpOrKeyID specifies how the key should be derived and whether AES encryption or decryption is performed. The following values of OpOrKeyID are supported:

● opOrKeyID AES _ ECB _ ENCRYPT (0xFFF10000) — data is encrypted with a 16-byte key at key using ECB mode.

● opOrKeyID AES _ ECB _ DECRYPT (0xFFF10001) -data is decrypted with a 16-byte key at key using ECB mode.

● opOrKeyID AES _ ECB _ DECRYPT _ MEDIA _ KEY (0xFFF10002) -encrypted KEY value at KEY is decrypted using the MEDIA KEY for the currently inserted MEDIA, then data at src is decrypted using ECB mode using the result as the KEY.

● opOrKeyID is any other value. The encryption key at pointer key is decrypted using the player key identified by opOrKeyID, and then the data at pointer src is decrypted using ECB mode using the resulting decryption key. (note: the content code may check the player's certificate to determine the key range of the player's master AES key set; these keys do not necessarily start at 0, and there may be multiple key sets.) although the keys selected by the opOrKeyID may be located in the player application, the keys may also be located (without limitation) in the drive, in the device driver, in the display/output device, remotely on the network, in a user removable smart card (or other tamper resistant chip), in a non-removable tamper resistant chip, split among multiple devices, and so forth. The first decryption operation (decrypting the encryption key of the specified content) may be performed by the device containing the identified key, while the bulk processing (i.e., decrypting the data at src) may be performed elsewhere (e.g., in a high-speed cryptographic module that lacks non-volatile memory for key storage).

Cryptographic operations, particularly those involving external devices, may also be implemented via TRAP _ deviceicovery and/or TRAP _ DeviceAccess. Cipher Block Chaining (CBC), counter mode, and other block cipher modes (optionally using an operation such as TRAP Xor) may be implemented by ECB operations using content code. Alternative embodiments may also provide algorithms other than AES and/or modes other than ECB directly.

UINT32 TRAP_PrivateKey(UINT8 *dst，UINT8 *src，UINT32 srcLen，UINT32 controlWord，UINT32 keyID)；

This operation transforms some data using the RSA private key selected by the key ID (typically 0) or some other asymmetric key in the player (or in a device accessible by the player). From the keyID, the length of the result and the type of operation (e.g., signature or decryption) are implicit. Information about available keys, including corresponding public keys and certificates (content codes can verify them), can be obtained using TRAP _ deviceicovery and/or TRAP _ DeviceAccess. The choice of which data to submit is determined by the content code (e.g., any function that can submit any data from the media and/or TRAP). For example, values submitted for signature operations may be associated with user interface (and other) events by incorporating event data (see TRAP EventGet) when generating the signed data.

For the player's master RSA private key (keyID ═ 0), this operation produces a 2048-bit RSA signature of the SHA-1 hash. The hash is computed as follows: (a) hashing as the value of 4 byte encoded srcLen (MSB first); (b) the hashing process specifies the contents of the user's buffer (i.e., the src bytes at src); (c) hash the value as a 4-byte encoded control word (MSB first); (d) hash the value of the media ID if the control word bit 31(MSB) is set; (e) if the control word bit 30 is set, the target pointer is set to PC +4, and dst is covered; (f) if the control word bit 29 is set, the hash begins with the current program counter (control word mod 2) ¹⁶) A code byte; next (g) if the control word bit 28 is set, the current value of the PC is incorporated into the hash. The SHA-1 hash result is then padded by adding "0 x00| |0x01| |0xFF (repeated 233 times) | | 00" to the start of the SHA-1 hash (prepend). The padded value is then raised to the player's secret exponent (secret exponent), modulo the player's public modulus.

For verifying the signature, the public exponent of the player is 3, and the public modulus can be obtained by the content code by verifying the player's certificate using a system-wide public password (which can be a constant included in the content code, optionally in fuzzy form).

The options provided by the control word allow the content code to obtain proof about the execution environment, such as detecting a situation in which the signature is executed by a compatible device different from the device containing the interpreter. A verifiable binding between the interpreter and the content code can be used to deal with situations where an attacker tries to use malicious content running on a legitimate player to produce cryptographic results for use by a malicious player running legitimate content.

Embodiments may support any combination of asymmetric cryptographic algorithms (RSA, DSA, elliptic curve variables, Diffie-Hellman, etc.), may support multiple operations (signatures, verifications, key protocols, etc.), and multiple key sizes. Symmetric operations may also be combined with asymmetric operations. It should be noted that certain cryptographic operations, such as RSA signature verification, may be implemented in the content code without any special TRAP, or using only general purpose performance acceleration operations (e.g., TRAP _ AddWithCarry, etc.). An example of a more complex cryptographic TRAP would perform some or all of the following steps: (a) performing an RSA public key operation to verify a signature of the data block; (b) if the signature is valid, performing an RSA private key operation to decrypt the block data in the verified portion to recover the symmetric key; (c) (ii) a If the RSA decryption is successful, some data (e.g., data in the signature block after the encryption key) is decrypted and verified (e.g., using HMAC-SHA) using the symmetric key, then (d) the decrypted data is processed into code using the interpreter.

In alternate embodiments, cryptographic support may be provided for signing, verifying, decrypting, encrypting, or otherwise processing any manner of input and output of other computing operations, such as other TRAPs.

UINT32 TRAP_AddWithCarry(UINT32 *dst，UINT32 *src，UINT32 len)；

This operation performs a multiple word addition operation with carry propagation. The value at src [0.. len-1] is added to dst [0.. len-1 ]. The values src and dst may each be checked to point to a large number stored as len words and encoded using the most significant word at the address src [0] or dst [0], respectively. The least significant words are located at src [ len-1] and dst [ len-1], respectively.

For example, the number 0x08090A0B0C0D0E0F would have len-2 and would be stored in such a way that 0x08090A0B is at the location specified by the pointer (e.g., src [0]) and the value 0x0C0D0E0F is at the byte offset referenced by the pointer plus 4 (e.g., src [1 ]).

If the source and target regions overlap, correct operation can only be guaranteed if src ═ dst. The return value of the operation is 1 if the last (most significant or left-hand) addition step produces a carry, and 0 otherwise.

(Note: TRAP _ AddWithCarry operations along with various other TRAP operations can also be implemented without a separate TRAP using content code, but a dedicated TRAP enables player designers to select the most efficient technology available on each platform, allowing better performance guarantees to be achieved in a wide variety of possible player designs.)

UINT32 TRAP_SubtractWithBorrow(UINT32 *dst，UINT32 *src，UINT32len)；

This operation performs a multi-word subtraction operation with borrow (carry) propagation. Specifically, the value at src [0.. len-1] is subtracted from dst [0.. len-1 ]. The values src and dst each point to a large number stored as len words and are encoded using the most significant word at address src or dst, respectively. For example, the number 0x08090A0B0C0D0E0F would have len-2 and would be stored in such a way that 0x08090A0B is at the location specified by the pointer (e.g., src [0]) and the value 0x0C0D0E0F is at the byte offset referenced by the pointer plus 4 (e.g., src [1 ]). If the source and target regions overlap, correct operation can only be guaranteed if src ═ dst. If the last (most significant, or left) subtraction step requires borrowing, then the return value of the operation is 1, and otherwise it is 0.

UINT32 TRAP_MultiplyWithRipple(UINT32 *dst，UINT32 *src，UINT32multiplicand，UINT32 len)；

This operation multiplies multiplicand by the number in dst [0.. len-1 ]. The length of the result is len +1 words. The most significant word of the result is returned and the rest is stored in dst [0.. len-1 ]. The value of dst should point to the larger number stored as len words and encoded using the most significant word at the address pointed to by dst.

The most significant 32 bits of the result are returned. (this is equal to the most significant 32 bits of the product of multiplicand and dst [0.. len-1 ])

void TRAP_XorBlock(UINT32 *dst，UINT32 *src，UINT32 len)；

This operation computes the result of the XOR operation of the two memory blocks. The data stored at src [0.. len-1] is exclusive-ORed with the data at dst [0.. len-1 ]. This operation is useful, for example, in generating CBC mode block cipher operations. The operation when src and dst blocks overlap is not defined. No return value is provided.

void TRAP_Memmove(UINT8 *dst，UINT8 *src，UINT32 len)；

This operation copies len bytes from src to dst. The result is correct even if the source and target tiles overlap. No return value is provided.

UINT32 TRAP_Memcmp(UINT8 *ptr1，UINT8 *ptr2，UINT32 maxlen)；

This operation compares the memory at ptr1 with the memory at ptr2, comparing up to maxlen bytes. If no difference is found, a return value of 0; if the value at ptr1 is greater at the first difference, a value of 1 is returned; and if the value at ptr1 is smaller at the first difference, the returned value is 0 xFFFFFFFF.

void TRAP_Memset(UINT8 *dst，UINT8 fillvalue，UINT32 len)；

This operation fills the memory with byte values specified by fillvalue. The target address is specified by dst and the number of bytes to be stored is specified by len. No return value is provided.

UINT8* TRAP_Memsearch(UINT8 *region，UINT32 regionLen，UINT8*searchData，UINT32 searchDataLen)；

This operation searches the memory for one or more bytes. Specifically, it finds the first occurrence of searchData (which has a length of searchDataLen bytes) in a region (which has a length of regionLen bytes). If searchData is completely in region [0.. regionLen-1], then a match will be found; matches that start within this range but extend beyond the end are not counted. The operation returns a pointer to the first match. If no match is found in the region, the return value is NULL (zero).

UINT32 TRAP_SlotAttach(UINT32 slot，UINT32 codeLen，UINT32reqPriority)；

This operation attaches to an existing non-volatile memory slot or configures a new slot (if the slot's specified value is zero). If the specified code (starting at the caller's PC and extending the codeLen byte) does not match the authority Hash of the slot, then the slot attach operation will fail (slot zero by default). (to obtain additional information regarding non-volatile memory support, see section entitled "protecting non-volatile memory")

UINT32 TRAP_SlotRead(UINT8 *dst，UINT32 slot)；

This operation attempts to read the non-volatile memory slot and, if successful, stores the result at the specified location. If the specified slot is not the currently attached slot, the private data portion of the slot contents is not returned. (for additional information, see section entitled "protecting non-volatile memory")

UINT32 TRAP_SlotWrite(UINT8 *newContents)；

This operation attempts to write to the currently attached non-volatile memory slot. (for additional information, see section entitled "protecting non-volatile memory.) the slot write operation is extremely fast (atomic), meaning the player guarantees that if the operation fails (e.g., due to an unexpected power outage) the operation will be fully completed or not started at all.

The TRAP _ SlotWrite operation ensures that the written data has the correct values for several parts of the slot, including creatorMediaID (the identifier of the medium where the content code of the slot was originally created), lastUpdateMediaID (the identifier of the medium where the content code of the slot was most recently written), lastUpdateSequenceCounter (the value of the global write counter, which is monotonically incremented once per write), and slotPriority (which specifies the rewrite priority of the slot).

The content code controls data written in the general area. Examples of information that may be stored include (without limitation) playback status information (such as the location and configuration of paused/stopped playback), audit information (including running hashes or other cryptographic authentication methods to audit data), high scores for electronic games, default information for automatically completing electronic purchases (user name, user address, credit card number, credit card expiration, mailing address, shipping address, telephone number, e-mail address, etc.), executable code (e.g., new security logic, patches to correct problems with the subject or player, etc.), keys (and other security information), and so forth.

The return value indicates whether the write operation was successful and the general status of the media (e.g., a warning if the non-volatile memory is nearing exhaustion due to an excessive number of write cycles). A read operation may be performed after a write to additionally verify that the write has succeeded.

UINT32 TRAP_MediaEject(void)；

This operation attempts to eject any removable media currently in the drive. Upon a successful call to TRAP _ MediaEject (), the interpreter can continue to operate, although in many cases the interpreter will then close on its own by calling TRAP _ Shutdown (). The player is not required to support auto-eject, in which case the operation will fail. (content code can use TRAP _ DeviceDiscovery to detect pop-up support and other player capabilities.)

In some cases, it may be advantageous to save a portion of the memory space of the content code while changing media. This may be useful, for example, to save larger amounts of data than easily stored in non-volatile memory when switching between optical disks in a multi-disk set. In this case, TRAP _ mediareject is used to eject the initial media. The user then inserts another piece of content (e.g., after being prompted by an overlay). The identity of the newly inserted content may be determined via TRAP _ deviceicovery. To prevent unexpected media changes, an explicit call to TRAP _ DeviceAccess is required to enable new media. The portion of the new media marked as authorized for normal reading may then be loaded. (some portions may be designated that they should only be read by the media's own content code.) embodiments requiring more complex media-to-media (e.g., compact disc to compact disc) linking capabilities may allow the code on the initial media to authenticate the second media and also allow the code on the second media to authenticate the source media. Media authentication may also be performed by the player, for example based on rules of digital signatures and certificates carried on the source and target discs.

UINT32 TRAP_MediaReadRequest(UINT32 offsetHigh，UINT32offsetLow，UINT32 len)；

This operation informs the media subsystem to begin retrieving certain data. In an exemplary embodiment, the value of len may not exceed 1 megabyte (1048675 bytes), including sector boundaries. (if the offset is not on a SECTOR boundary, i.e., not an integer multiple of SECTOR _ SIZE, then the length must not exceed 1 megabyte minus the SECTOR offset, which is calculated as offset Low modulo SECTOR _ SIZE.) the SECTOR _ SIZE is currently defined as 2048 bytes.) the player allows buffering of at least two outstanding requests (e.g., one currently being serviced and one next to be serviced). This allows the content holding drive to be continuously busy. The player will typically use a separate one megabyte waiting buffer for each pending request. A return without any error means that a read will be attempted (i.e., the request is not significantly in error), but there is no guarantee that the read will actually succeed. (see TRAP _ MediaReadFinal.)

While this operation only requires a read to be performed (and does not actually load any data into the memory area of the content code), alternative embodiments may specify the target address and detect whether the read has completed, for example, by receiving an event or by checking whether the target buffer is full. If the approach is used with code-based NVRAM security capabilities (e.g., see TRAP _ slottach), security measures may be required to ensure that pirates do not use pending requests to breach the security code associated with the unlocked NVRAM slot or otherwise attack security. For example, the player may suspend or disable media reading while the NVRAM slot is unlocked, and/or deny NVRAM slot attach requests while the operation is pending.

UINT32 TRAP_MediaReadFinal(UINT8 *dst)；

This operation checks whether the oldest (first entry) requested read has completed. If NOT, a return value of STATUS _ NOT _ DONE is returned. If no read is pending, a return value of STATUS _ NOT _ FOUND is returned. If the read request fails, a STATUS _ ERROR is returned. Otherwise, the requested data is transferred from the buffer of the drive to the memory space of the content code at the specified address, and the value STATUS _ OK is returned. If the address is 0xFFFFFFFF, the data is discarded.

It should be noted that special reads (such as read of burst area, data read with error detection/correction disabled, etc.) are configured and performed using TRAP _ DeviceAccess instead of this operation.

UINT32 TRAP_MediaWrite(UINT32 offsetHigh，UINT32 offsetLow，UINT8 *src，UINT32 len)；

This operation writes predetermined data to the medium, starting at a predetermined offset. (the offset is a 64-bit value, encoded as a 32-bit upper value and a 32-bit lower value.)

This operation is only applicable to media formats that support writing. The writable area may also be limited to a particular portion of the media. Writing may also be prohibited in certain situations (e.g., if the media has been changed, if the recorder identifier on the media does not match the current device, if the media does not have a valid certificate authorizing use of the writing capability, etc.).

TRAP _ DeviceAccess may be used to provide any necessary authentication or key protocol needed to protect or enable writes. For write-once media, attempts to overwrite previously written portions may be denied (and risk destroying the media at that location) unless explicit authorization has been obtained (e.g., via TRAP _ DeviceAccess). (although not generally required, such writing may be useful in certain situations, e.g., to make the medium self-destruct in response to an attack.) if the drive allows direct control of write head modulation, tracking control, error correction codes, read/write head optical characteristics, or other configuration parameters, these may also be adjusted via TRAP _ DeviceAccess. The characteristics of the written media may be modified for forensic purposes, such as allowing the content owner to determine which writing device made a particular piece of optical media.

UINT32 TRAP_EventGet(UINT8 *evBuf，UINT32 len)；

This operation checks whether any events (such as user interface operations, security changes, etc.) are pending and, if so, stores information about the first (or highest priority) event at the address specified by the event. If no event is FOUND, the value STATUS _ NOT _ FOUND is returned and the content of the event does NOT change. Otherwise, the trap returns a STATUS _ OK and stores information describing the event at evBuf (but not more than len bytes).

The data returned in the event buffer (evBuf) depends on the event. If a user interface event is returned, then the following data structure is stored at the memory address specified by evBuf:

typedef struct {

UINT32 Source； /* Device type that produced event */

UINT32 Action； /* Actual/suggested action for event */

UINT32 Char； /* UTF-8 value of event(if applicable) */

UINT32 Direction；/* Compass values for event */

UINT32 Xpos； /* Pointer X position for event */

UINT32 Ypos； /* Pointer Y position for event */

UINT32 Reserved[10]；/* Do not interpret(future use) */

} EventInfo_UserInterface；

the Source field identifies the device from which the event originated. The interpretation of the Source field may be predicated in advance or predicated by the content code (e.g., via information obtained from TRAP _ DeviceDiscovery). Examples of possible sources that may be specified include (without limitation): remote control, keyboard, panel keys, mouse (and other pointing devices), media drive, external device, timer, codec, unknown/unspecified source, etc.

The Action field specifies the actions proposed for the event or the actions that trigger the event. This value may be modal (e.g., affecting the current state of the player) or may be constant. The action may change the playback state or have other effects. Examples of possible actions include (without limitation): play, pause, stop, rewind (at various rates), fast forward (at various rates), slow motion (at various rates), power down, pop-up, channel down, select, enter, volume adjust (or mute), lead/menu select, change of view angle, skip-forward, scene select, user language select, subtitle control, video angle (video angle) change, select, back, forward, yes, no, buy, exit, help, error, output device change notification, playback environment reconfiguration notification, security alert, and so forth. If unknown (such as the case where there is no action corresponding to an event), then this field is zero. (Note that this field is valid for user interface events as well as other events the most significant 16 bits of the value identify the structure of the subsequent field, e.g., EventInfo _ UserInterface, EventInfo _ SecurityAlert, etc.)

The Char field specifies the characters (e.g., encoded using ASCII, double-byte, etc.) corresponding to the key. If unknown (such as the case where there are no characters corresponding to the event), then this field is zero.

The Direction field specifies the Direction of the event indication, or if not, zero. The direction may be any angle, although the direction may be quantized to some predetermined value (e.g., north/up, northeast/up-right, right/east, etc.).

The Xpos and Ypos fields indicate a location if the event can be interpreted as a movement or action of a pointer on a standard X/Y grid. If the event does not correspond to the X and/or Y coordinates, then the corresponding field is set to zero.

It should be noted that a single event (such as a key press action on a remote input device) may be interpreted in a variety of ways. For example, on some input devices, the button used as "up" also corresponds to the number 8. In this case, an event will be generated with an "up" direction and a Char field of the number "8". The content code will use its current knowledge of what input is needed to decide which is appropriate. (in an alternative embodiment, the player may provide separate capabilities or information to assist the content code in interpreting user events, or to allow the content code to specify how to interpret events with several possible interpretations.) if the content receives an unknown event type, it may safely ignore it (unless otherwise indicated by a key bit specified in the source domain).

Other data fields may be provided for non-user interface events (such as events announcing device addition, device removal, device reconfiguration, other playback environment configuration changes, requests for data from external components, notifications that operations have completed, etc.) or for events from other kinds of user interfaces (such as voice recognition capabilities or digital cameras configured to monitor user gestures). For certain events, it may be necessary for the content code to invoke an additional TRAP (such as a vendor-specific TRAP) to obtain additional information.

It should be noted that while the TRAP _ EventGet operation uses polling to detect changes, alternative embodiments may use interrupts or other well-known mechanisms to process events.

UINT32 TRAP_CodecOutput(UINT32 idx，UINT8 *buf，UINT32 len)；

This operation transmits the data to the codec. A simple player may support only one CODEC (e.g., CODEC _ AUDIO _ AND _ VIDEO) or two CODECs (e.g., CODEC _ VIDEO _ MPEG2 AND CODEC _ AUDIO _ MPEG), while a more complex player may support many, for example, support multiple kinds of content streams AND enable features such as picture-in-picture. Codec parameters may be set using the TRAP _ DeviceAccess operation.

UINT32 TRAP_CodecSetTime(UINT64 time)；

This operation sets the master codec clock. A zero value for the prescribed value causes the clock to resynchronize with the video time stamp embedded in the data provided to the TRAP _ codeoutput. This command is buffered using a video buffer, so the effect is delayed until the command is encountered. This operation is used to enable real-time video splicing and to allow seamless switching of content codes from one compressed video/audio stream to another, using TRAP _ codecfrush.

UINT32 TRAP_CodecSetRate(UINT32 rate)；

This operation sets the rate and direction at which the codec consumes the data. The rate value is converted to a signed integer and scaled down by a factor of 64. For example, a rate of 0 means "pause", 128 is fast forward at 2 times the normal playback speed, -256(0xFFFFFF00) is rewind at 4 times the speed, and 16 is slow forward play at 0.25 times the speed. If the requested value is not supported, the codec picks the next closest value by ignoring the symbol and rounding to the larger, maximum rate of the player respecting. The exception is some fractional playback rate where the codec should not be rounded to 0 (pause) or 64 (normal). If a negative playback rate is specified (opposite), the codec (via TRAP _ CodecStatus) will request the video GOPs, typically in reverse order. By default, the audio is muted for playback rates other than 64.

UINT32 TRAP_CodecFlush(void)；

This operation refreshes the video and audio codec buffers. This command is typically used if the content code wishes to delete data in the codec buffer in order to quickly switch from one stream to another. For example, if a user requests a jump in 1 minute, the content code may use this operation to clear any data in the codec buffer so that the newly committed data can be decoded immediately.

UINT32 TRAP_CodecStatus(CodecInfo *info)；

This operation retrieves information about the codec's FIFO queue and the next video or audio block desired by the codec. The returned data values include the current timestamp (including timestamps for audiovisual information currently being displayed/output, information currently not being compressed, and information currently in the codec buffer), the amount of time until the codec buffer becomes empty, the number of bytes available in the codec buffer, the location (e.g., next, previous, seek distance) and type (e.g., complete GOP or "I" frame) of the next data that should be added to the codec buffer (e.g., when MPEG-2 video is played back at high speed, this may be the previous "I" frame). Where applicable, separate information is provided for each codec (audio, video, etc.).

UINT32 TRAP_OverlaySetup(UINT32 idx，UINT32 width，UINT32height)；

This operation configures an overlapping plane with an exponent value idx, which has a specified size and is blank (completely transparent).

UINT32 TRAP_OverlaySetPosition(UINT32 idx，UINT32 x，UINT32 y)；

This operation sets the (x, y) position of the prescribed overlay plane on the display (where 0, 0 is the left corner). This operation does not actually show overlap; it only specifies where the overlap will be displayed when TRAP _ OverlayShow () is called.

UINT32 TRAP_OverlayShow(UINT32 idx，UINT64 pts)；

This operation shows overlap. The pts value specifies the time at which the overlay should occur, e.g., for synchronizing the overlay with the underlying video.

Multiple calls to TRAP _ OverlayShow (along with calls to other overlay operations to actually create the appropriate image, set the palette, etc.) may be used to create an animation menu, simple picture-in-picture video, and any manner of other animation overlay.

UINT32 TRAP_OverlayHide(UINT32 idx，UINT64 pts)；

This operation hides but does not clear the overlap. Hiding the overlay makes it available for later display again. The overlap is concealed at a defined time (pts).

UINT32 TRAP_OverlayClear(UINT32 idx)；

This operation clears the overlap. Clearing the overlap erases its contents so that it needs to be set again before it is displayed again (see TRAP _ OverlaySetup).

UINT32 TRAP_OverlaySetPalette(UINT32 idx，UINT32 *color，UINT8*trans)；

This operation specifies overlapping palettes, including color (e.g., RGB or YUV) and transparency (opacity) for each of the 256 palette values. Changes to the palette can be used to animate the overlay or modify the overlay (e.g., to highlight the edges around the selected area, change the opacity of the translucent overlay pane, make the image visible, etc.).

UINT32 TRAP_OverlayBitmapDraw(UINT32 idx，UINT32 x，UINT32 y，UINT32 width，UINT32 height，UINT8 *bmp)；

This operation draws the bitmap over a defined overlay. An overlap drawn beyond the boundaries of the overlap region may produce errors, or may produce results that are aesthetically unpredictable. However, in that case the player should not overflow the buffer or cause any other security breach. The parameter bmp specifies the image to be rendered (which may be compressed or uncompressed). Alternative embodiments may provide rendering operations or may provide the ability to perform scaling and other image manipulations, offloading these processes from the content code (typically computationally frequent).

UINT32 TRAP_OverlayTextDraw(UINT32 idx，UINT32 x，UINT32 y，UINT32 size，UINT8 *text)；

This operation draws the text over a defined overlap. The first eleven items in the palette are used for the coloring of text (including antialiasing with a translucent edge). The content code may also use image rendering capabilities to display text, for example if the player lacks the required fonts, character sets, etc.

If the text line does not fit the overlap, it is pruned (crop). No support for line breaks is provided; this is the responsibility of the caller. The size parameter specifies the size of the text to be drawn, and may be player default (e.g., reflecting user preferences, characteristics of the current display, etc.).

UINT32 TRAP_OverlayRectDraw(UINT32 idx，UINT32 x1，UINT32 y1，UINT32 x2，UINT32 y2，UINT32 color，UINT32 filled)；

This operation draws a rectangle over the specified overlap. The input parameters specify the overlap index (idx), the top-left coordinates (x1, y1), the bottom-right coordinates (x2, y2), the color, and the Boolean value (filled) indicating whether a rectangle should be filled.

UINT32 TRAP_SockConnect(UINT8 *name，UINT32 port)；

This operation opens a socket-based network connection on the port specified by the port to the address specified by the name. TRAP _ DeviceAccess may be used to configure socket settings and determine whether a network connection is currently available, potentially available (e.g., by attempting to dial up via a modem), or determined to be unavailable. The existence and reliability of network connections depends on implementation (e.g., portable devices integrated with cellular phones are likely to have network connections, but devices without any wireless connectivity support may not).

Player support for socket/network operations is optional, but standardized to provide a consistent interface through which content can access remote network resources (when available). Socket support is asynchronous; content requiring synchronous access should be polled until the desired data has been retrieved. The detection and configuration of network parameters is performed via TRAP _ deviceicovery and TRAP _ DeviceAccess.

UINT32 TRAP_SockClose(void)；

This operation closes the currently open connection.

UINT32 TRAP_SockRecv(UINT8 *buf，UINT32 len)；

This operation receives data in buf from an open connection.

The content code controls how the received data is used. Examples include (without limitation) obtaining the latest security code, checking revocation status, processing payments, buying (and purchasing) goods/services, downloading attached content, downloading updated offers/advertisements (including pricing and purchasing information), implementing multi-user interactive systems (movie viewers chat, etc.), web browsing (web rendering and/or browsing capabilities implemented by means of a player, as the case may be), and the like.

UINT32 TRAP_SockSend(UINT8 *buf，UINT32 len)；

This operation sends the data pointed to by buf to the open connection.

UINT32 TRAP_DeviceDiscovery(UINT32 dev，UINT32 qID，UINT8 *buf，UINT32 *len)；

The player environment discovery process (TRAP _ deviceidiscovery and TRAP _ DeviceAccess) provides content code with information about the playback environment and provides the ability to control the environment. For example, content may wish to perform the following operations, such as (without limitation): determining player settings (such as default player language, volume, brightness, contrast, output resolution, etc.); discovering which alternative procedure calls are supported; determining playback environment configuration (attached device, active software driver/program, status of playback environment components, etc.); an authentication output device; lookup components (whether present locally, directly connected, connected via a network, etc.) and access optional or removable devices.

TRAP _ deviceicovery provides an answer to the device specified by dev to the question specified by qID. To know information about the playback environment, the playback code may ask each device a list of standard questions. Examples of supported problems include (without limitation): what qID (question ID) are supported by the device? What, if any, are the device IDs of the parent and child devices of the device? What is the role of the device in the system (storage device, user interface, video display, speakers, portable device, networking components, etc.)? What is the identity of the device (serial number, manufacturer information, model number, version, date, expiration date, etc.)? What is the certificate (and other cryptographic data and capabilities) of the device? What cryptographic keys do the device contain (or have access to)? Which roles of the device (record, forward, display, etc.) are currently in use and which roles are inactive? What protocols are supported by the device and which protocols (and protocol parameters) are currently enabled? Is the device support for receiving executable code? What, if supported, are execution environment features (interpreted or local, supported specification version, multi-threaded or single-threaded, security credentials)? What is the value of the current timer of the device (including time zone, etc.)? What configurable parameters are supported by the device and what is its current value? What is the state of the device?

The standard problem list may expand over time; devices manufactured before a particular QUESTION (qID) becomes part of the standard QUESTION list will respond to the query with the qID error code STATUS _ resolution _ UNKNOWN. Also note that a question on the standard question list will always have the most significant bit (bit 31) of qID cleared. This most significant bit set problem ID is reserved for extended device-specific problems. (content code designed to discover extension information about a particular device must know the device's extension qID list and response method.)

The calling routine should pass the maximum length of the buffer pointed to by buf as a location (in bytes), which is indicated by len. The value returned in Len will indicate the number of bytes actually written to buf.

When a device is connected to the system, the player assigns a device ID to the device. Disconnecting a device from the system does not cause the device ID to be lost or reassigned to another device. Device ID zero is reserved for the main player itself (although the player may also have an additional ID). The device ID is unchanged until new media is inserted or the TRAP _ deviceicovery is invoked with a device ID (dev) null. When TRAP _ DeviceDiscovery is invoked with dev set to zero and qID set to zero, all currently assigned device IDs are discarded, a rescan of all devices is performed if appropriate, and the device IDs are reassigned. A change in device or device configuration typically generates an event (acquired by TRAP _ EventGet).

The information provided by TRAP _ deviceidiscovery may be used by the content code to decide whether to play, how to play or what to play, derive decryption keys or other cryptographic parameters, transform data that will then be executed as code, identify (or solve) compatibility issues, assess risk, decide player capabilities, identify user preferences, and perform other secure and non-secure roles.

TRAP _ DeviceDiscovery should not change the state of the system; the operation of changing the state of the device should use TRAP _ DeviceAccess.

UINT32 TRAP_DeviceAccess(UINT32 dev，UINT32 opID，UINT8 *buf，UINT32 *len)；

This operation requests the device specified by dev to perform the device operation specified by the opID. The operation is typically device specific. This TRAP (and/or socket TRAP) is typically used for messaging between or within devices, as well as for setting configuration parameters and generally managing the playback environment. The content of the parameters passed depends on the opID. Depending on the opID, a buffer (buf) may be used to transfer information from or to the content, or both.

TRAP _ DeviceAccess can be used to implement a very wide range of capabilities. For example, security parameters (such as keys and other parameters that affect how data is loaded from physical media) may be specified using TRAP _ DeviceAccess. The operations are also used to interact with remote devices and other components, including hardware and software components, including without limitation: transmitting data, receiving data, performing a key agreement, determining a revocation status, performing authentication, changing a configuration status, controlling power management features, terminating/controlling a process, and so forth.

For example, TRAP _ DeviceAccess may be used to transfer a copy of a movie to a remote device. The content code running on the sending device may first identify the target device and the appropriate operational ID for the transfer. It will also perform any device authentication, key exchange or other desired security operations. (although security analysis is most commonly performed before transmission, key distribution and other security related processes may additionally or alternatively be performed during or after the main data transmission.) then it will submit portions of the movie (optionally together with interpretable code if supported by the recipient) to the remote device. The format of the transmitted data is negotiated by the content code and the target device and is ultimately controlled by the content code. For example, the content code being transmitted may select, rescale or otherwise transform the content from a plurality of formats supported by the target device, embed the forensic mark in the content, and decrypt/re-encrypt the content before providing it to the target device. The code transmitted with the content may also be different from the code actually being interpreted by the transmitting device (e.g., if the interpreter is of a different type, performs a different role, etc.). Code, keys, data, and other portions may also be omitted or modified, for example to remove functionality not supported by (or not authorized to be performed by) the recipient device, such as the ability to make subsequent copies. The code or data may also be provided in encrypted form and need not be decrypted by the transmitted content code. (in some cases, the sending device may not even have access to the decryption key.) typically, the content will be partially loaded from the media by the sender and then output after undergoing any necessary security processing or other transformations. The recipient device may also run interpreted code. For example, device-to-device transfer may involve first transmitting some initial code to a recipient that will perform any required security checks for the recipient, then managing the receipt of subsequent data. (e.g., TRAP _ DeviceAccess may be used to receive data and store it in, for example, a file system, or TRAP _ CodecOutput may be used to display data at the receiving end.) the sending code may perform security and revocation checks, manage the secure portion of the interface protocol, etc. even when sent to a non-programmable device. In some cases (e.g., if the device and transfer protocol are newer than the content code), the content code may allow the device to manage the security of the transfer process while monitoring the process to the extent needed and/or practicable (e.g., by accessing details of the security process and preventing transfer if a security issue is identified). The transfer may be accompanied by NVRAM slot writes, media writes, a "handshake" with an external server, or other procedures (for example) to enforce restrictions such as a "copy-once-only" policy.

UINT32 TRAP_RunNative(UINT8 *signature，UINT32 sigLen，UINT8*code，UINT32 codeLen)；

This operation is used to allow the content code to execute native code on the player. The player may require that the local code be digitally signed by the player manufacturer or another trusted party. (the purpose of which is to prevent malicious content from running malicious native code.) the operation of native code is typically specific to the player implementation (or any other device that ultimately runs the native code). Thus, the content code typically uses information about the characteristics of the player (e.g., as determined from TRAP _ deviceivediscovery) to determine what native code the player requires (or conversely, whether the player is compatible with some native code).

Examples of the use of TRAP _ RunNative include (without limitation):

● installing software updates to the player or other parts of the system (e.g., by writing updated code to non-volatile memory contained in the consumer electronics device, modifying software programs installed on the PC, etc.);

● updating the keys or cryptographic parameters stored in the player;

● to scan the playback environment (memory, storage, etc.) for malicious (or potentially malicious) software (such as video capture software masquerading as a video driver, media emulation software masquerading as an optical disk drive or other media input device, a debugger to tamper with the executing program, any in-activity software that the TRAP _ device discovery does not report correctly, any software that lacks a valid, unrevoked digital signature, etc.);

● detect whether malicious (or potentially malicious) modifications have been performed on the device (such as unauthorized firmware changes, reconfiguration of FPGAs, replacement of hardware components, etc.);

● verifying that a device is of the intended type (see below) in terms of its certificate, public key, symmetric key, and other cryptographic attributes;

● provide a solution to bugs (such as defects in the player's overlay/menu capabilities, memory leaks, memory corruption problems, incorrect interpreter operations, performance problems, security policy interpretation defects, etc.); and

● enable direct access to peripherals (e.g., to obtain otherwise inaccessible information about the system or to modify system state in a manner not supported by existing TRAPs). TRAP RunNative can help reestablish security in situations where a pirate finds ways to extract cryptographic keys from a class of legitimate players and uses those keys in conjunction with a malicious software program. In this case, it is generally not feasible to revoke the keys of all vulnerable players, since many such players will be owned by legitimate users, who may be dissatisfied with revoking their devices.

An exemplary media carries countermeasures against key extraction attacks and includes content code to:

first, the content code on the media determines the purported serial number of the player by checking the player's certificate. The player serial number implies both the type of player and the specific cryptographic key (e.g. in TRAP _ Aes) carried by the player. (certain exemplary key management methods are described in the "exemplary symmetric key management" section.) next, the content code verifies that the player knows the keys that it should know. (this may be done, for example, by calling a TRAP _ Aes where src and dst point to a buffer containing encrypted code or data needed for playback, len contains the buffer length, key points to the value of the decryption key of the buffer that has been encrypted using the player key of interest, and the oporKeyID reference player key; multiple TRAP _ Aes calls may be performed, including the case where the output from a previous operation is used to formulate the input for a subsequent operation; other steps may also be included, such as performing a TRAP _ Aes operation with constant input, then "correcting" the result by an XOR operation or adding a "correction" value.) the keys for vulnerable players are vulnerable because these players require additional authentication to distinguish between the case of performing playback on a vulnerable player and the case of performing playback on a malicious player using keys extracted from a vulnerable player, the key verification step will fail (or at least not be fully completed). This may be performed by executing a TRAP RunNative that runs native code configured to distinguish emulated from legitimate players, then modify the interpreter state according to the result (e.g., by returning the result value, decrypting or otherwise processing portions of the interpreter's memory region based on the result, etc.). Alternatively or additionally, the native code may have an effect outside the interpreter, such as by communicating with an external device, modifying the output (e.g., to introduce a forensic mark), and so forth. The operations performed by the native code may then be required by the content code for proper playback, such as by incorporating or otherwise requiring the results of derivation of decryption keys for the video or required code/data.

The native code is only likely to be successfully distinguished unless an emulator is ideal (which is an extremely difficult prerequisite to implement given the complexity of modern computing devices). Examples of features that native code can be used to distinguish legitimate players from emulated players include (without limitation): the ability to run certain types of native code, the values stored in hardware registers, the effects of modifying hardware registers, memory contents and checksum/hash values, behavior when performing non-standard operations, correct implementation of vendor-specific security features (e.g., informally recorded security capabilities in a video decoder chip), codec rounding errors, handling of error conditions, optional user interface components (such as LCD displays or keyboard inputs), the presence of capabilities not available to legitimate devices, and the performance and timing of operations. In an exemplary embodiment, the content specifies native code that performs one or more player security tests, derives keys based on the test results, and decrypts a portion of the memory area of the interpreter using the derived keys. The content code is then configured to play correctly if all (or substantially many) checks of the native code indicate that the player is legitimate. If the player is illegal, the content code and/or native code may stop playback, report an error, require additional authentication, require a player upgrade, deny decoding to the end of the movie, disable the satellite feature, play at a reduced resolution, or respond in other ways that reflect the higher risk associated with the playback environment.

UINT32 TRAP_VendorSpecific(UINT32 select，...)；

This operation serves to allow player manufacturers to increase support for their own secure and non-secure operations. By way of example (and not limitation), certain embodiments may provide file access (open, read, write, search, close, set attributes, etc.), access to vendor-specific security operations (such as non-standard cryptographic support that may serve as a backup in the event that the primary cryptographic capability is compromised, secondary cryptographic transformations, security features in hardware video decoding circuitry, etc.), access to special capabilities not available via TRAP _ DeviceAccess (three-dimensional display, scent output, joystick vibration, etc.), access to the original frame buffer contents, etc.

Integrated security service

Exemplary embodiments may allow a certifying entity (or other entity) to provide a suite of integrated security services to content authors. While security services may be provided by the content owner itself, outsourcing these capabilities to third parties may reduce the need for the content owner to participate in the process, while allowing economies of scale, for example, by enabling one security provider to serve multiple content owners. Regardless of whether the security service is provided by a single entity or by multiple entities, the related tasks may include (without limitation):

● develop security code or services that combine the audiovisual content with security counter measures, decryption logic, forensic mark embedding functionality, enforcement of revocation policies, integration with non-volatile storage capabilities, and integration with non-security feature user interfaces;

● use automated search tools and/or manual processes to find potential pirated material available via computer networks and other distribution channels, manually and/or automatically inspect and analyze the pirated copies to recover information embedded in the forensic marks, then use the recovered information to gather information about the pirate's device or method;

● collect, archive, and analyze other information about piracy, such as by analyzing discussions between the pirated software/device and the pirate (e.g., in an online chat room);

● use the collected information to help reduce piracy, including (without limitation) undoing the pirate device, enacting counter-measures against pirate attacks, assisting in prosecution of suspected pirates, and so forth;

● manage revocation lists of keys, players, and other components, such as keys, players, and other components that are suspected of being compromised, unsecure, involved in piracy, or otherwise should not be used to decrypt content. The list can be managed electronically and includes (without limitation) a plurality of parameters associated with the status of each item, such that revocation data can be customized to meet risk profiles associated with individual topics, processes, and the like;

● generate or obtain input/output for block decryption operations (such as TRAP _ Aes), e.g. for editing content so that it can only be decrypted by non-revoked devices;

● develop or manage countermeasures to attacks, including those directed to specific players. For example, in a scenario where player manufacturers must develop and digitally sign local code-based security counter measures, the services may include (without limitation): identifying situations requiring the counter-measures, providing information about risks to the manufacturer, assisting counter-measure development, providing tests for counter-measures (including security tests and compatibility tests), developing code or policies used by the content to identify the playback environment in which each counter-measure should be used, integrating counter-measure code with other decryption processes and other security features (e.g., to prevent counter-measures from being skipped or bypassed), and combining counter-measures from multiple individual player types/manufacturers on the media;

● manage data associated with the non-volatile memory slots, including keys, codes, identifiers, security policies, and other attributes;

● operate in conjunction with or in conjunction with online or other network-based or interactive components (e.g., for providing enhanced user or player authentication steps when decoding a device or environment involving one or more devices or environments with unreliable security);

● performing quality control on the completed media;

● combine content with special marketing features, user features, non-standard features present on individual platforms, and the like;

● performing player compatibility testing;

● developing and combining code for detecting players with problems (including (unrestricted) menu program errors, codec limitations, display limitations, non-working features, correctable security defects, etc.) and applying appropriate solutions (which may include avoiding affected operations, using unaffected simplified features, installing player patches and executing native code to deal with the problems);

● in conjunction with a replicator (replicator) to ensure that media is correctly manufactured with the appropriate code and data to achieve the features described above; and/or

● provide any manner of other tasks to assist content owners, player developers, users, law enforcement, or other parties.

Evidence obtaining markMemory embedding and recovery techniques

To obtain the maximum possible security against relatively large scale collusion attacks (i.e. attacks where pirates combine decoded outputs from multiple decoding devices, the general intention being to clear forensic marks that could otherwise be used to identify and revoke the collusion device), it is generally advantageous to have the ability to introduce a relatively large number of variations in the output. It is of course possible to store a completely separate version for a complete MPEG-2 video GOP, although the storage requirements would be unacceptably high if a large number of alternative video sequences (such as millions of alternatives in a movie) had to be stored. To accommodate the situation, it is advantageous to minimize the amount of required storage space.

Although the specific requirements and attributes required for forensic marking vary depending on the situation, desirable attributes typically include that underlying changes are manifested compactly (meaning that less storage space or bandwidth is required for coding changes), durable (meaning that the changes can be recovered from reduced quality copies, such as copies made from television screen recordings using consumer camcorders), plausible (meaning that they cannot be automatically identified and removed by inspection of the output), and that they are aesthetically acceptable (meaning that changes do not unduly degrade the quality of or experience with the content). These requirements may vary (e.g., between topics, content author requirements, playback environment characteristics, etc.).

For an exemplary optical video disc that supports forensic marking, the content author looks for or generates a number of alternatives (or other modifications) that can be applied to the compressed video. These replacements are identified as part of a video compression process that is modified to identify potential changes, then evaluated for suitability according to a number of criteria (e.g., storage size, durability, plausibility, artistic acceptability, etc.). If the change is appropriate, it is output as an appropriate change. For example, compression logic may be configured to identify locations where changing a value of a single bit (or a single byte, a single word, a single block, etc.) results in a suitable alternative video sequence.

In an alternative embodiment, conventional compression algorithms may be used, and alternatives may be generated and validated as a post-compression step. For example, automated software may be used to (a) identify candidate modifications to a video stream, for example by using a (pseudo) random number generator to select an arbitrary byte of compressed video and a new value for that byte; (b) performing trial decompression of the video and rejecting the candidate modification as invalid if the stream is changed to become invalid; and (c) comparing the output of the trial decompression with the result of decompressing the original stream, and rejecting the candidate modification if the difference does not meet the requirement. For example, step (c) may reject too small a modification (i.e., not durable enough) or too large a modification (i.e., not plausible and/or artistically acceptable). Additional tests may be performed to verify that the modifications will not interact with each other (e.g., in some cases, if the modifications are applied separately, they may be acceptable; if the modifications are applied simultaneously, they may be unacceptable). The modifications that pass the test are saved.

When editing exemplary media using forensic marks, an initial compressed video data stream is prepared. This data consists of the main compressed video to which some modifications have been applied as appropriate (which may include some other modifications that replace or corrupt the video as appropriate). Data structures are prepared that identify valid modifications to the video (e.g., apply previously identified but unapplied modifications or remove applied modifications), including any modifications that are mandatory to make the video playable. The replacement can be very compact (e.g., a 24-bit byte offset and an 8-bit replacement value in an MPEG GOP can be represented with 4 bytes), enabling as many as millions of changes to be defined in just a few megabytes of data.

The content author then prepares program logic to select and apply the changes based on the playback environment characteristics. This program logic should be configured to apply changes to the video sequence, where the combination of changes applied is typically based on information useful for forensic purposes (such as serial number, value to cryptographically identify the device, model/manufacturer information, information about the connected device, etc.). Additionally, the program logic should be configurable to apply any changes needed to produce a valid video stream (at least when operating in an acceptable playback environment). (having "forced" changes may be useful to help thwart attacks where pirates attempt to disable the portion of content code to which the changes apply). The content code logic may include the use of cryptography, such as using player keys to decrypt alternate sets only on those players to which those alternates should be applied. Similarly, the content code may include the use of error correction codes, for example, to enable a party recovering marked video to recover player information even when the mark recovery is not reliable (e.g., due to an attack or quality degradation). The embedded value may include a digital signature, MAC, or other value that authenticates the embedded information so that the party recovering the indicia can be confident of the validity of the recovered information.

When a pirated copy is recovered, the content author can analyze the copy to identify the changes that are present. While this analysis may be done manually (e.g., by comparing frames of the pirated video to each possible variation at each location, then mapping the list of variations back to the playback environment characteristics), this analysis process may be automated for greater efficiency and to enable analysis of markers with greater complexity. An exemplary automated forensic mark analysis system is implemented using a computer with customized software. The analysis software starts with the original compressed video, the modified list and a digital representation of the restored pirated video. Next, the analysis software matches the frames in the original video with the frames in the pirate video and identifies the transitions (rotations, scales, warps, color shifts, brightness adjustments, time shifts, etc.) of the frames of the pirate video that most closely match the corresponding frames of the original video (and/or the original video to which the modifications have been applied). The analysis software then compares the frames (or portions of frames, or sets of frames, etc.) of the pirated video against the corresponding portions of each variant of the original video. The software then calculates a score based on the similarity/difference indicating how closely the restored video matches each variant. This score may be calculated, for example, using the least squares difference between the (converted) pirated video image and the variant of the original video. In calculating the scores, areas not affected by the change may be ignored and further adjustments may be made for distortions such as interleaving, frame-to-frame blurring, and so forth. The image analysis software may also provide a "manual mode" user interface that allows the operator to view frames of the pirated video (with or without adjusted transitions) alongside variations of the original video (with selectable magnification and highlighting to aid in visually localizing the changes); and provides user interface options to allow the operator to select which changes are present in the pirated video (or indicate that the changes are unknown), advance and retreat frames in each video source, quickly advance to the next change, and save the current program state. The output of the image analysis process (whether performed manually or automatically) is a list of relative scores assigned to possible changes that may be present in the video. (in a simplified form with the output identifying only the most likely option for each variant). An automatic and/or manual process is then used to convert the recovered change data into information about the playback environment. For example, if the marker embedding is initially based on the output of an error correction code applied to the player sequence number, the recovered selection value may be converted into the input of an appropriate decoding process that will recover the sequence number (assuming the number of errors is not excessive). Similarly, if the selection process is performed using a pseudo-random number generator (PRNG) seeded with a portion of the sequence number, the analysis process may involve associating a PRNG output using each possible seed value with observations of the pirated video.

The changes may also be embedded in the content using other means than modifying the compressed video stream. For example, the content code may introduce the modification by controlling the player to overlay an image over the decoded video. For example, forensic marks may be embedded by drawing one or more semi-transparent overlapping frames on MPEG-2 decoded video (or similarly, by having the content code modify the output frame buffer directly or indirectly). The overlap may also be highly visible. For example, a dynamically generated moving translucent overlay stating "Screener for firstname LastName' s.do Not copy." may provide a public deterrent to piracy, and may result from determining the name of the viewer (e.g., from the burn area of the disc, from NVRAM slots, from a server, etc.) and displaying the appropriate overlay. The overlap can also be used to correct or modify the uncompressed video, for example by drawing on (intentionally) defective parts. Overlapping may be very efficient for storage space on the media, as the amount of data required to represent code for rendering the overlap may be very small. The overlap-based marking makes it efficient to generate video portions with a large number of variations (a smaller portion of a single video frame can easily be made to uniquely identify the player, e.g. by simply overlapping a representation of the player sequence number in that area). Overlay-based marking can also simplify the manufacturing marking process, which can vary widely, as there can be many options for screen location (x, y) and time, for example, when a faint semi-transparent overlay image may be displayed. These features may be particularly helpful in identifying the device in situations where a pirate seeks to hide the source of his copies by combining the output from multiple players. Forensic marks may also be embedded in other data including (without limitation) audio, still images, control data, media writing patterns, and the like.

Media and content authentication

The content code and/or player may cryptographically authenticate the media when inserted and/or when subsequently loaded with data.

In an exemplary embodiment, all or some of the individual data portions (e.g., sectors) of the media are digitally signed using a hash tree. The root hash is digitally signed by the supervised format entity (or another trusted entity) and placed on the media. The root hash signature may also identify the copying and/or production facility, the copyright owner, the release date, criteria describing the player device that is authorized (or unauthorized) to access the media, and other such information. When (or after) a block of data (e.g., a sector, GOP, track, file, etc.) is loaded from the media, it can be verified by the drive, content code, player application, and/or other player device/component by combining the loaded data with the appropriate intermediate hash value to recreate the root hash. The value of the root hash may be cached after verifying the media signature so that the (relatively slow) public key signature verification step need not be repeated for each read. Similarly, intermediate hash values may be stored, cached, computed as needed, or retrieved from the media with the data chunks. The media may also include multiple root hashes or other authentication schemes may be used (such as by verifying a digital signature on each sector, GOP, or other portion of data). To reduce storage overhead, signature and padding schemes may be used that allow message recovery. The digital signature may also identify portions of the contents of the optical disc, such as the boot code contained on the optical disc or data stored in a writeable (or re-writeable) portion, or all of the data.

The signature (or other cryptographic or non-cryptographic values) may also specify or limit the operations that may be performed by a particular disc or portion of code. For example, the digital signature may be issued by a certifying authority that authorizes and allows content access to particular player features or capabilities. The authorization may be used to ensure that a license fee has been paid or to prevent the production of unauthorized pirated media. In an exemplary embodiment, each content author (or its replication facility) wishing to mass-produce an optical disc containing a movie will provide the certifying entity with information identifying the optical disc to be produced. The information may include, without limitation, the subject, the identity of the legitimate copyright holder, the number of copies to be authorized, a hash of at least a portion of the disc content, the media serial number, the desired capabilities required, and a digital signature of the authentication request. In response, the copyright holder will receive one or more digital signatures authorizing the production of the media. The certifying entity may also receive and process payments from content authors (or their agents). In this way, the licensing fees are likely to be directly related to the specific capabilities (security or otherwise) actually used by the content. The restrictions on the operations applied to the content code may also be based on a non-cryptographic flag (e.g., similar to a broadcast flag used to indicate whether a broadcast television signal may be copied). Permissions may also be based on previous actions (e.g., denying access to network resources by content codes that have accessed private user information to ensure that user privacy is maintained, granting permission to acquired users or gaining greater access to authenticated content codes from a remote server, etc.), and may be different for different threads, portions of content code, etc.

The digital signature may be distributed with or separate from the content and may be provided on any part of the media and may also be accompanied by encryption keys, logic for deriving decryption keys, security policy information, and so forth. For example, in the case of optical media, it may be advantageous to place a digital signature on the portion of the media that is separately writable for each disc (thereby providing an authenticated unique disc serial number, e.g., for use with media revocation capabilities, to clearly specify which devices should be able to play the media, etc.).

For media containing non-volatile memory (EEPROM, flash, etc.), the unique data may normally be stored, while other media types may require other technologies. For example, a stamped optical medium may carry data in a Burst Cutting Area (BCA), which is typically written using a high-energy laser. Intentional defects or altered patterns may also be introduced into the media surface and read by the player and/or content code (e.g., by directly processing the resulting read results with error detection and error correction disabled). For semiconductor-based ROMs, fuses and other write-once features may be used.

In addition to signatures and certificates, media uniqueness zones can be used to carry (without limitation): location information, encryption keys (e.g., keys that allow a particular player to decode current or future media such as dailies (screeners), presentations, or other optical discs intended for controlled distribution; keys that allow reading, decrypting, and/or writing player non-volatile memory data, etc.), unencrypted keys (e.g., written after production of the embossed media to prevent decoding of media or data stolen from the reproduction facility by pirates), identification information (such as recipient name, e.g., for display in an overlay and for use in forensic marking), marketing and promotional data (e.g., values that allow participation in trials, lotteries, online services, etc.), telephone numbers, data network addresses, executable code, or other cryptographic or non-cryptographic data in any manner that may be used by the content code and/or player. When loading data from the disc unique area, the drive may apply a one-way transformation (e.g., SHA hash, HMAC-SHA keyed by a value specified by the content code, RSA public key operation, etc.) so that it does not output (e.g., does not output to an application or the content code) the information needed to forge the content of the disc unique area. The recording device may also use hashing or other cryptographic transformations to prevent pirates from making accurate illegal copies using information extracted from legitimate media. The media unique zone may also be pre-recorded (e.g., with a serial number on a blank consumer recordable media) or written by the recording device (e.g., with an identifier of the recording device, which may be digitally signed, which may be verified by legitimate devices to ensure that the recorder has not been revoked and may be used in recovering illegal copies to identify and/or revoke the recording device used to make it).

For media formats that support media authentication and anti-counterfeiting techniques, such as modulated pit (modulated pit) features or wobble track content, as outlined in U.S. patent No. 6,646,967, values derived from these features may also be read (or detected) by the player and authenticated by the player and/or the content code. After reading the physical characteristic, the drive may apply a one-way cryptographic transformation before outputting this value, so that a malicious party who knows the transformed characteristic cannot forge the underlying characteristic in a way that is acceptable by the unmodified drive. The content code (and/or the drive, player application, or other component) may authenticate the converted feature (e.g., by verifying that the media is signed with a value from a trusted party that has the feature).

Boot, secure analysis and replay

The actual operation of an exemplary player with an exemplary optical disc will be described beginning with the insertion of the optical disc into the drive. The interpreter is first booted by loading and executing an initial portion of code and/or data from the optical disk. This initial portion may be smaller and simpler, for example, it may simply inform the user that the theme is being loaded, then begin loading additional code and data from the media into the memory area of the content. This code may then be loaded with additional code (e.g., it may check the player type, then load code that is specific to that player type). Any number of code loading checks may be performed depending on the player design and media. The player may also detect the absence of code (or features required to run the code) from the inserted media and if so, the player uses the capabilities built into the player to play the optical disc. The support is applicable, for example, to allow playback from legacy media formats such as DVD, CD, DVD audio, and the like.

The exemplary media then uses the player's cryptographic interface (e.g., TRAP Aes) to derive one or more theme-specific decryption keys. The content code is configured such that only non-revoked players can derive a valid decryption key. These decryption keys may then be used, for example, to decrypt additional encrypted code, video, or other data (to accomplish this, content code may use (without limitation) techniques such as broadcast encryption, key-encryption-keys, obfuscated software, and so forth). Booting may also include loading data from the media, decompressing the data as needed, and performing any manner of security analysis operations (discussed in more detail in the following subsection).

The actual playback then typically involves repeatedly performing various steps or checks, which may include (without limitation):

● handle the event. This may include detecting and processing user interface events (such as keystrokes, pressing a remote control button, mouse movements, pointer/cursor movements, selection inputs, etc.) and other events (e.g., power down requests/notifications, hardware reconfiguration requests/notifications, software change requests/notifications, error warnings, media eject requests/notifications, etc.) (see TRAP _ GetEvent.) the appropriate method for processing an event may depend on the event, the subject, the player properties, and the state of the playback process (e.g., the logic for processing an event when a menu is displayed may be different than the logic used when a video is played). For example, certain events may be handled (without limitation) by switching to a new video stream, changing player configuration bits, requesting an action (e.g., invoking a "media pop" TRAP in response to a pop request), updating menus, changing (e.g., animating, updating, etc.) overlay graphics, initiating/updating/etc. a network connection, changing playback configuration (playback speed, etc.), loading and running new content code, jumping to a new location in a video stream (which may require changing/clearing buffered media requests, clearing a codec for data buffering, etc.), terminating playback, performing security checks, displaying errors, and so forth. Certain events may also require the content code to check that the requested operation is authorized. Operations that cannot be performed immediately may be buffered until they are performed. Certain events may also be ignored.

● manage media interfaces. In an exemplary implementation, the media of the processing routine is responsible for ensuring that there is a stable supply of data available to the video and audio codecs and other uses. For example, if the medium is an optical disc, the content code may check the state of the drive, retrieve data that has been successfully read, submit a new read request, clear a read request that is no longer needed, provide hints for read-ahead (read-ahead) capability or cache (e.g., loading data in each possible bifurcation of an upcoming branch in the video to ensure uninterrupted playback), specify where in the memory area of the content code the data should be loaded (or elsewhere, e.g., codec, frame buffer, decryption module, etc.), check for errors, control how errors should be handled, specify a cryptogra phic key for the drive or other component, provide authentication information in conjunction with the drive read/write request, specify decoding parameters (such as error correction information, keys, sector address mapping, etc.) Read head depth/focus/etc., file access privileges, etc.), etc.

● Security handling: this logic may perform any additional required decryption or processing steps, such as deriving keys, authenticating the loaded data (e.g., using MAC, hash tree, digital signature, etc.), and running the executable portion (e.g., security code associated with a particular portion of audio or video). This step may also include embedding forensic marks (e.g., by selecting which portions of the data to load for output, modifying the data, etc.). In an exemplary embodiment, this operation includes deriving the keys of the MPEG GOP, performing AES decryption operations on the data of the GOP, and pre-and post-processing before/after decryption using content codes (reordering data, block XOR, substitution, byte modification, etc.) to ensure that knowledge of the block AES key itself does not allow a pirate to decrypt the content of the disc.

● convey the data to the codec. This code can also detect and handle error conditions, such as a situation where the codec is starved of data (codec state) because the data needed from the media is not available. This code may also detect the codec state to ensure that the codec buffer does not overflow or underflow, and to ensure that the media interface code is loading the correct data.

● handle overlapping and special features. This logic is responsible for drawing and removing menus, overlays, subtitles, and similar features. It also handles picture-in-picture video and certain kinds of forensic marks (such as forensic marks drawn using overlays).

Special cases (such as games/puzzles, menus, processing of menu selections, hidden "easter eggs", etc.) may require special codes. If a multi-threaded interpreter is provided (such as a Java virtual machine), separate threads may be used for different operations (managing events, overlaps, video, etc.), and the interpreter's support for messages passing between threads and/or shared memory regions may be used for synchronization and control between threads. Similarly, status checksums and messaging may be used to ensure that the interpreter is synchronized with other components.

The player may also provide a default processor for various operations, for example, to improve user interface consistency, reduce content editing effort, increase performance, and so forth.

After completion (such as the case where the user presses an eject button on the player), the content code may be notified that a shutdown is in progress. The content code may then notify the remote device, clear its internal state (e.g., complete any required non-volatile memory writes, etc.), and exit. If the content code is not exited within a predetermined period of time (e.g., 5 seconds), the player device terminates the content code and ejects the media.

Secure analytics operations

The content code may analyze the playback environment for security issues. This process typically includes obtaining and processing information about the player and other parts of the playback environment. This information may include digital signatures and/or cryptographic certificates for players or other components that the content code may verify.

This information obtained from the player describes the characteristics (or purportedly the characteristics) of the player and the playback environment. Certain characteristics, such as the presence of a particular TRAP, are reported directly. Other features may indirectly infer, for example, that the particular combination of cryptographic keys in a player may be determined in part or in whole by the serial number of the player. Players that masquerade as legitimate players but do not have the correct cryptographic keys may be "caught" because they are unable to perform cryptographic operations (decryption, signing, etc.) that use keys that they do not have. Similarly, other inconsistencies may be used to identify problems.

The security analysis process may be involved in a variety of playback-related processes, including deriving keys for compressing video, code, audio, and/or other data. For example, if a particular type of legitimate player supports the ability to run native code (code running on a local processor in the machine, as opposed to code running in a standard interpreter/virtual machine) and/or supports unrecorded calculations specific to the player type, the content may use these capabilities to authenticate the player type. If the content finds that it is running on a player that claims to be a particular model but is unable to correctly perform the operations supported by that model, then the content can reasonably infer that it is running on a device that is disguised as a player type, e.g., using keys extracted from this type of player that was maliciously compromised.

The security check may involve analyzing any combination of components or attributes. For example, characteristics of the media, media drives, and hardware components may be used to detect counterfeit players. Content sold on pre-recorded or "suppressed" media may query the drive to determine if it is running on the consumer recordable media, and if so, it refuses to play because this should never happen. If a particular subject matter allows recording to a consumer-recordable media under certain circumstances (e.g., if payment has been made), then content may allow playback from the consumer-recordable media only if there is a valid digital signature (issued by an authorized representative of the content owner) that specifically authorizes playback from the media with a particular serial number and/or identifier of a particular recording device, for example.

Security checks may be performed on the output device, device driver, and other playback components, including the content intended (or likely) to be received. This capability is particularly useful in situations where the processing content may be recorded using a malicious or compromised output device. The verification operation of the output device is limited only by the capabilities of the device. For example, output device verification may include, without limitation, sending a native code to an input or output device (e.g., to detect security issues, fix bugs, etc.), performing cryptographic "handshakes" with other devices, testing a device's keys against a revocation list carried on a medium, and so forth. The output device may also request verification of the player, in which case the appropriate verification may be provided by the player, the content code, or a combination of these (or other components). If multiple output devices are connected in a string (e.g., a player device may send digital audio to a mixer, which provides the digital audio to an amplifier, which then provides analog output to a speaker), each device may provide information to the player on how it plans to process the content and allow the originating (or other) device to pass the message to a subsequent device. In this way, the content code can authenticate each device in any long string of devices (or network of devices) involved in the playback process. If an untrusted device (or an unauthorized device such as a recording device) is detected, the content code may ensure that an appropriate response is made (including without limitation refusing to play, refusing to output to the untrusted device, controlling an intermediate device not to send content to the untrusted device, reconfiguring the untrusted device to correct problems, reducing output quality, performing additional security authentication steps, etc.). If there is a connection to the Internet or another data connection, the security check may include downloading additional security-related information from a remote website. Similarly, the remote device and local storage (e.g., NVRAM) may also be used to obtain useful information, such as the latest certificate revocation tables or digitally signed security code that is more up-to-date than the code on the media.

Although security checks are typically performed prior to playback, the content code may perform security checks at any time. For reconfigurable playback environments, or where other new security-related information may be available, it may be advantageous to perform additional security checks periodically or often. If a significant change is detected, the content code may terminate playback or pause playback until confidence in the playback environment can be reestablished.

A table or decision tree may be used to quickly select which security analysis code (if any) is appropriate in the context of a particular player attribute. The security code not applicable to current players need not be run (or even loaded from media), thereby preventing any unnecessary performance impact and preventing compatibility issues that may result from running the security code on players that do not support it. As described previously, security checks may be combined with cryptographic key derivation operations (e.g., in situations where a device requiring a particular security check must actually perform the check to correctly derive the required key, but does not require that the device of the security check be able to directly obtain the key).

Exemplary Key management

An exemplary player is initialized by its manufacturer with a unique key combination. These keys are obtained from a key authority authorized by the entity controlling the media format. The key authority receives requests from authorized manufacturers, verifies the requests, provides a player key set, and receives payment for the key (and corresponding license fees). The key set for the exemplary player consists of 128 AES keys each of 128 bits derived from the highest level 256-bit AES key (known only to the key authority), a 32-bit group ID (identifying the manufacturer of the player) and a 32-bit device ID (identifying the serial number of the player). The group identifier and the device identifier together uniquely identify the player and are represented in the player's digital certificate.

In an exemplary embodiment, each of the 128 keys (key ID values from 0 to 127) within the key set is derived by the key authority by first computing a key selection block from the key ID, group ID, and/or device ID. The key selection block is then padded (if necessary) and encrypted using the highest level key. The resulting value may be post-processed (e.g., truncated) to produce the actual key. The method for deriving the key selection block from the specified parameters depends on the key ID. The following table illustrates exemplary rules that may be used to convert the key ID, group ID, and device ID into a key selection block.

Key ID Content of key selection block listed by key ID

31 group ID | (device ID > Key ID)

32..63 (group ID > (key ID-32)) | |0x00000000

64, 79 KeySelector (group ID, device ID, 15, 8)

80..83 KeySelector (group ID, device ID, 16, 8)

84 KeySector (group ID, device ID, 17, 9)

85 KeySelector (group ID, device ID, 18, 9)

86 KeySector (group ID, device ID, 19, 10)

87 KeySector (group ID, device ID, 20, 10)

88 KeySelector (group ID, device ID, 21, 11)

89 KeySelector (group ID, device ID, 22, 11)

90 KeySelector (group ID, device ID, 23, 12)

91 KeySector (group ID, device ID, 24, 12)

92 KeySector (group ID, device ID, 25, 13)

93 KeySelector (group ID, device ID, 26, 13)

94 KeySector (group ID, device ID, 27, 14)

95 KeySelector (group ID, device ID, 28, 14)

96 KeySelector (group ID, device ID, 29, 15)

97 KeySelector (group ID, device ID, 30, 15)

98 KeySelector (group ID, device ID, 31, 16)

99 KeySelector (group ID, device ID, 32, 16)

1000 x00000000| | device ID

101..127 group ID | | device ID

An exemplary function KeySelector (group ID, device ID, g, d) that assigns keys to a pseudo-random subset of devices (according to their group ID and device ID) is:

lethash [0..19] equivalent of the bytes of the SHA hash of the Key ID | | group ID.

Let AND_MASK＝(1＜＜g)-1.

For i＝0 upto d-1:

Let n＝hash[i]mod(g-i).

Clear the nth set bit in AND_MASK.

EndFor.

Let XOR_MASK＝hash[16..19]AND(AND_MASK XOR((1＜＜g)-1)).

Computer deviceHash [0..19] as the SHA hash of the Key ID group ID device ID.

Return 0x00000000||((deviceHash[16..19]AND AND_MASK)XORXOR_MASK).

Note that: "|" indicates concatenation. "0 x" denotes a 32-bit hexadecimal value as follows. "<" indicates a left shift operation. "-" denotes subtraction. "AND" means a bitwise logical AND. "XOR" means a bitwise logical XOR.

It should be noted that different kinds of keys are included. For example, key 0 and keys 101-127 would be uniquely assigned to the device. Instead, keys 1-31 will be shared among a larger and larger set of devices in the same group. Keys 32 through 63 are shared among multiple groups. Finally, keys 64 to 99 are shared between various (in this case pseudo-random) subsets of devices. The key 100 is shared by devices with the same device ID across different groups.

It is important to adequately protect the device key. For example, placing the actual key of the device on the media risks leaking the player's key if the security of the subject matter is compromised. Similarly, providing the device key to the content publisher may place the key at risk in the event that the content publisher's security is breached. To address these risks, the present invention does not require that the entity that prepares and encrypts the content be trusted. For example, a key management authority may provide a service by which any party may identify a set of player keys and one or more input values. In response, the authority may provide the results of decrypting (or encrypting) the specified input with each identified key. Alternatively, the content publisher may provide the plaintext/cyphertext pairs that it chooses. In either case, parties editing the content may obtain the plaintext/cyphertext pairs, but may not obtain the key itself. These pairs can then be used in the production of secure media.

The production of the exemplary media includes the following steps: (a) a content publisher defines a set of player keys that are unknown to any revoked player, but each valid player contains at least one key in the set; (b) the content publisher selects an arbitrary plaintext value; (c) the content publisher securely transmits the desired plaintext value to the key authority along with the identification information for the key in the selected set; (d) the key authority verifies that the plaintext value was not previously submitted by the other party; (e) the key management authority derives each player key in the requested set and encrypts a plaintext value using each key; (f) the key management authority provides the resulting ciphertext to the content publisher; (g) a content publisher encrypts a portion of the content (or some code, key, or other data) with a plaintext value; and (h) a content publisher stores the encrypted content and the list of ciphertexts and corresponding code on a medium, the code configured to identify whether a player running the code includes any keys in the set; and if so: determining the key ID in the player, looking up the ciphertext corresponding to the key ID in the ciphertext list, and decrypting the encrypted content portion, call TRAP _ Aes, for example, by having the encrypted content portion as the source data, the ciphertext as the key parameter, and the selected key ID value. The content code may then provide the results of the decryption to a codec or otherwise use the data as appropriate.

Alternate embodiments may use (without limitation) multiple levels of decryption operations, combining cryptographic results with forensic marking and other operations, using multiple key authorities and using security codes or other processes to further protect or process values (keys, plaintext, ciphertext, etc.), and so forth.

If public key cryptography is used, the key authority may provide (or disclose) the player's public key (or identity-based cryptography may also be used to make a key list unnecessary). For digital signature keys, the key authority may also provide a reference signature (e.g., a message/signature pair) used by the content code. The public/private key may be shared among a group of devices (e.g., by using an operation such as a KeySelector as a seed for a strong PRNG to generate a key pair, randomly generating and distributing keys, etc.).

Of course, the above roles may be divided among multiple parties. For example, a key management authority may also manage a centralized revocation list, such that content publishers do not need to determine which keys are valid and which are invalid. Similarly, content publishers may outsource security-related tasks to other parties (including key authorities).

The above exemplary process for deriving a player key is deterministic. Other embodiments may involve randomly generating keys and other techniques may be used. The operation used to derive the key (e.g., AES encryption) is exemplary and other operations may be used instead, such as MAC, public key operations, other algorithms, and so on.

Version(s)

When decoding content, typically either (a) the content will be older than the player or (b) the player will be older than the content. In both cases, playback should occur normally, assuming that the player correctly implements all the required TRAPs (including any necessary cryptographic keys) and satisfies the security rules enforced by the code associated with the content. Of course, if the content code is written loosely, playback may not work automatically if the player is defective or if serious security problems have occurred after editing.

To handle the situation where the content code fails to play correctly on a legitimate player, the content may be edited, for example, to check the player for a security overlay key for a particular disc, and if found, to use the key to decrypt a portion of the content code that avoids one or more security checks or other operations that would normally be performed. This "circumvention" logic may be carried on the media in encrypted form, ensuring that it cannot be used unless the decryption key has indeed been released. If an overlay is required, the overlay key may be stored, for example, in a non-volatile memory of the player (e.g., in encrypted form), retrieved via a network, accessed via a TRAP, etc. Measures that do not affect security, such as disabling a graphical menu of a player with display restrictions, may be user configurable and do not require security authentication.

The content code may also be configured to enable the user to cope with situations where a security failure or risk is detected. For example, if a modem, internet connection, or other data channel is available, the content may communicate with the authentication server to obtain an updated security code and/or to obtain permission to continue playback. A code may also be displayed (or audibly played) that the user may provide to an automated toll-free telephone service that provides an activation value. (the service may receive information via the telephone, e.g., by using a voice recognition system, by detecting DTMF audio, or by detecting sound passing into the handset from the user's speaker. similarly, information may be returned to the user for keyboard entry, passing from the handset to a microphone on the player, etc..) the response may be verified by the content code (e.g., by checking a digital signature, MAC, fuzzy checksum, etc.) and/or used for subsequent cryptographic processing (e.g., as a key). Challenge/response authentication results may be used with forensic marks, for example, to allow tracing copies back to a particular user or identifier. For example, if the activation value is unique and included in the forensic watermark, the content owner may trace back to the process that generated the given activation value using the forensic watermark to track the recovered pirated copy. Thus, it may be advantageous for the content owner to obtain information about the user (e.g., the phone number of the dialer using ANI or the dialer ID, name, credit card number, etc.) before providing the activation value. The activation value may be stored in non-volatile memory of the player (e.g., for future use and for use by other subjects).

Media encoding and decoding

In an exemplary embodiment, the content code may specify (via TRAP) the parameters needed to read and decode the data from the medium. The actual processing of the sectors read from the optical medium may include any or all of the following steps:

● provide sector decoding parameters to the optical drive (or other component responsible for performing some or all of the sector decoding).

● drives read the original data corresponding to the requested data (e.g., sectors). The actual loading may include using the sector identifier (or other addressing information) to look up the data on the medium, then actually loading the appropriate data from the medium. The drive may also remove or process unencrypted portions (such as navigation fields) included with the load data.

● apply error correction to the original sector data. The error correction process may involve an adjustable polynomial or other parameter. The content code may also disable error correction and/or detection, for example if it wishes to perform these operations on its own.

● decryption or other cryptographic conversion may also be included with error correction and performed before and/or after ECC. The decryption process applied to the uncorrected data can be selected to avoid transmission errors. For example, decryption with a stream cipher (e.g., RC4 or AES in counter mode) may be performed before correcting bit errors. Decryption (or other processing steps) may be applied by a driver, content code, codec, driver, or any other component.

The decryption process may also be selected to have a one-way nature, e.g., such that a pirate cannot use the recorded output to calculate the output that would result using other decoding parameters. For example, the drive may compute the key for each sector as a HMAC-SHA of 160-bit (or other size) import value (which is not returned by the drive) that uses the key specified by the content. Without knowledge of the imported values, a pirate cannot convert a decrypted output generated using a known content-specified key into an output that should be generated using other content-specified key values. Thus, pirates lack the information needed to copy the media or emulate it (e.g., using a hard drive and a malicious device driver). Although it is possible for a pirate to store a decoded sector representation for a particular key value, the copy/emulation will fail whenever a content code requests a sector using a corresponding key whose output is unknown. Since the total number of decoding keys may be extremely large, e.g., 2 for a 256-bit key²⁵⁶It is not possible for a pirate to store all possible sector decodings. The content code may perform different combinations of requests and, for some requests, use or check the actual data loaded.

The player (or other component) may perform an asymmetric cryptographic transformation on the sector data. For example, block signatures may be used to deter pirates from making new themes without obtaining a license. In one embodiment, the public key consists of a 2048-bit RSA modulus embedded in the drive (although it could also be obtained from the media, extracted from the certificate,etc.). To improve the efficiency of the signature verification operation, the RSA modulus is generated to an integer power close to 2, e.g., with the most significant 128 bits equal to "1". When the media is produced, each block (e.g., sector) is first randomized by xoring the sector data with a keystream generated by seeding (seed) a stream cipher with a media ID, the address of the block, and a SHA hash of the block data. The block data is then divided into 256-byte (2048-bit) blocks that are each digitally signed by performing a modular exponentiation operation on the block using an RSA private key. The signed block is recorded with the SHA hash. Thus, a block extends only 20 bytes (less than 1% if the block is a sector of 2048 bytes). Assuming that the stream cipher is effectively randomized, the probability that the input to the modular exponentiation is greater than the public modulus is negligible (about 2) ^-128). Therefore, no special handling is required for this case. When a block of data (e.g., a sector) is read and decoded from the medium, a corresponding check-sum decoding process is performed and includes (a) reading a 256-byte block and SHA hashes; (b) performing a modulo exponential operation on each block using the public modulus and the public exponent (e.g., 3); (c) reversing the randomization process, e.g., by computing a keystream using the contained load SHA hash value, xoring the keystream with the block; (d) verifying the integrity of the decoded data by hashing the media ID, the chunk address, and the chunk data and comparing the result with the loaded hash value; and (e) returning the decoded data block if the hashes match. If the hashes do not match, an error is returned. If performance is an issue, the test may be performed probabilistically (e.g., on randomly selected sectors) and/or only on areas containing more critical data.

When writing recordable media (or making a master for copying), the recording device may receive values that it converts using a one-way cryptographic function (such as SHA, HMAC-MD5, a one-way function constructed using AES, etc.) and writes to a particular location on the media (see below). In this way, a pirate cannot use legitimate recording equipment to copy the media because he would not know the correct input (e.g., hash pre-mapping). Other authentication values (such as digital signatures) may also be stored. The security value may be applicable to any (or all) portions of the media.

The media security values may be stored as ordinary data or may be stored in "special" areas that include additional protection against direct reading and/or are specially encoded. Because the amount of secure data may be relatively small (e.g., as small as 128 bits or less), storage techniques with relatively low density and performance may be used. For example, known data may be encoded in pit encodings or variations in track position (wobble) of optical media. Data may also be hidden in redundant bits typically reserved for error correction, differences in sector age, navigation fields, and so forth. Data may also be encoded at different physical disc locations (e.g., inside or outside the area that is typically readable, or at different focal depths).

The data on the media may include indicator bits, pit coding changes, or other indicia indicating whether certain processing or security steps related to the data should be performed. For example, a sector security flag may be used to indicate that the data contained in the sector should be transformed using a public key and/or may be released only if the drive has first received a cryptographic authorization. (the authorization may include, without limitation, requiring SHA hashing of the sector contents, performing a successful challenge-response authentication with the recipient whose key was not revoked when the media was made, verifying the digital signature authorizing the release of the data, receiving the key to correctly decode the sector, etc..) the data may also be marked so that it can only be released in encrypted form. (this is especially important in personal computers and other systems where data may be transferred over an untrusted bus or channel).

Although the above exemplary embodiments are described primarily with respect to optical media, similar techniques may be applied to other media types such as magnetic media. In the case of solid-state media (such as EEPROM/flash memory) and other storage technologies where the media itself may perform computations, the media itself may perform cryptographic processing and may also include and drive internallyA player application, etc. (which may also have an interpreter). The media need only include the amount of non-volatile memory needed to actually store the compressed content (e.g., roughly 30 gigabytes for high definition movies), but it can be made very large (e.g., 2) using cryptography or other techniques²⁵⁶Bytes) of the address range. If this is done, it will not be possible for the pirate to make a perfect pirated copy, because it is not feasible to store (or even read) the entire address range, and there is no general way for the pirate to decide how parts of the address range will actually be used. For example, the content code may require the use of different regions in each playback. This general approach may even be used in situations where the main player application is not programmable but the media (or media drive/interface) is programmable.

Conditional access key stream forensics

The design of pay television receivers generally targets all security critical components to be placed in a smart card or other removable device so that security failures can be handled by replacing the smart card. Typically, the replaceable module is used to derive a decryption key, which is provided to a general decryption circuit contained in the set-top box. A major drawback of conventional implementations is that a pirate can record the output from an authorized device and forward the key (and any other desired data) to an unauthorized device. One related attack involves recording and forwarding the video itself.

Tracking the attack may be extremely difficult or impossible. For example, compromised computers may be used by pirates to anonymously forward keys and data to unauthorized viewers via the internet. The key may be sent in UDP packets with a fake "source" address, making tracing very difficult. Although the system operator can access unauthorized data by joining a piracy service, there is no way to track the source of the attack. In other cases, the tracking data may be practical, but the source may be located in an area where law enforcement is not effective.

With current systems, the sequence of decryption keys used to decrypt the video (and the decrypted video itself) is the same for each subscriber. These keys may be transmitted (e.g., from the conditional access smart card to the video decoder chip) using device-specific key encryption, but the actual video decryption key is still global. Thus, a set-top box has been compromised or reverse engineered (which is not very difficult because the design of the set-top box is generally fully standardized) and a pirate with a legally predetermined account can determine and forward the sequence of video decryption keys. This attack typically does not require the actual compromise of the security module itself, preventing the security module replacement from being a valid counter measure.

To cope with such attacks, the system operator needs to identify the specific account (and thus, the security module) used by the pirate to extract the keys and other forwarded data. Once this account has been identified, the system operator can terminate the account (e.g., by ceasing transmission of the key needed for access in a form that can be utilized by the pirate's security module, by wirelessly transmitting an encrypted message that temporarily or permanently disables the pirate's security module, etc.) and any associated accounts (e.g., accounts from devices connected to the same telephone line, accounts sharing the same billing address, accounts having a nearby physical location, accounts paying using the same credit card or other payment instrument, etc.).

To accomplish this identification, the system operator includes forensic marking information in the actual sequence of decryption parameters output by each security module.

In one embodiment, prior to video decoding, the conditional access module outputs a conventional decryption key and a byte substitution that is applied by the set-top box to decrypt the plaintext. When creating a video sequence, the system operator identifies multiple locations in the video stream where byte substitution can produce acceptable variations (polymorphs). In addition, certain bytes in the video stream are corrupted so that to form a valid (or comfortably viewable) video stream, the bytes are replaced with mandatory. A legally ordered conditional access card is configured to output a unique combination of byte substitutions, including a set of mandatory byte substitutions large enough to recreate a viewable stream. Each module may output alternative unique combinations, making it possible to match the forwarded output back to a single device. Alternative embodiments do not necessarily use byte substitution; the conditional access module can specify any manner of translation, including (without limitation): addition, exclusive-or, block move, delete, insert, bit reversal, and more complex operations (including specifying the actual code that should be executed by the interpreter or microprocessor of the decoding device).

The approach described above requires support in the set-top box and therefore cannot be used with many legacy systems. For legacy environments, a different embodiment may be required where the content provider combines a stream that is valid when interpreted in each of two different key states.

The content provider combines the portions of the video stream that are acceptably decoded when decrypted using each of the two different keys (or key states). Existing satellite or cable television systems typically encrypt portions of the video (such as 10 second segments) each using a different key. For this disclosure, one or more segments will be generated that can be decoded using more than one key.

In an embodiment, a video compression process is modified to identify a plurality of acceptable modifications to an initial block of compressed video data. The block is then encrypted using the first key, producing a ciphertext that will be suitable for transmission to a set-top box that decrypts using the first key. The block is then decrypted using the second key. If the resulting plaintext would also be decoded as an acceptable output on a device keyed by the second key, the block is saved and the process is repeated for each subsequent block of data. If decryption using the second key indicates that the ciphertext will not form an acceptable stream on the device keyed by the second key, then a new value for the starting block is attempted. After sufficient attempts, the system operator will be able to gradually combine video streams that can be decrypted using each of the two (or possibly more) keys. The quality of the resulting video using each key will depend on the computational effort expended, the technique used to select the candidate block, the video compression technique used, the reference video, and other factors.

More computationally efficient encoding methods are also possible. For example, in most video compression schemes, including MPEG-2, it is possible to use fields, such as the annotation field, to interleave the data regions encrypted using each key. This technique typically increases the size of the video data, but is computationally efficient and does not degrade the output quality.

An exemplary video stream begins with conventionally encoded data (e.g., digital video and/or audio encrypted or not encrypted using a single key) up to a location where a key change is expected. The key change signal is then encoded. The first ciphertext block after the key change is selected such that (a) a first decryption key is used that decrypts to the appropriate value for the next 8 bytes of the compressed video stream, and (b) a second decryption key is used that decrypts to a sequence of bits that controls the decompression apparatus to ignore subsequent bytes (e.g., by initiating MPEG annotations) or otherwise cause subsequent bytes to have relatively little effect on the decompressed output. To find a block with these characteristics, the compression device or process may, for example, start with the desired plaintext when decrypting using the first key, then try random values of the first and/or second keys until a key pair is found that also gives an appropriate result in the case of the second key.

Subsequent portions of the stream are generated such that the ciphertext (a) is generated as a compressed video that is decrypted using the first key, and (b) is ignored (or processed with relatively little impact) when decrypted using the second key. This stream may be prepared by encrypting the video data using a first key and, if necessary, decrypting the resulting data using a second key to verify that the results are appropriate (e.g., not prematurely terminating the MPEG annotation). Minor adjustments to the plaintext may be required and repeated to correct any situation where inappropriate plaintext may occur (e.g., the data will be prematurely terminated from being ignored, or an inappropriate length will be transmitted, or an illegal stream will otherwise be generated, or an unsightly stream interruption will be caused, etc.). Finally (such as when near the end of an MPEG annotation, when a video block encoded using the first key is near completion, etc.), the ciphertext stream may include data that, when decrypted using the first key, causes the decompression process to begin ignoring data. At this point or shortly thereafter, the "ignore data" state ends with the second key, and the stream continues with ciphertext that yields valid compressed video when decrypted using the second key, but that is ignored when decrypted using the first key. The stream continues alternating data segments that produce compressed video when decrypted using one of the keys and annotation data when decrypted using the other. Finally, a key change is triggered (e.g., due to a key change notification present in the stream), either reverting to normal video or starting a new video segment that can be decrypted using a new key pair.

If a pirate simply forwards the key sequence, it may be acceptable for both decryption results to produce the same video at decompression. However, if the pirate forwards the decompressed video, the video sequence generated by decrypting using each of the key values should be different.

It should be noted that alternative embodiments may include data that can be correctly decrypted using more than two keys or data that can be decoded (using the same or different key values) using more than one cryptographic algorithm. Examples of supported decryption algorithms may include (without limitation): DES, AES, triple DES, DVB block cipher, IDEA, any other block cipher of any mode (CBC, ECB, etc.), RC4, SEAL, any other stream cipher, etc. For embodiments in which encryption may be disabled on the set-top box, the state in which encryption is disabled may be used as a key state (e.g., where the transmitted data may be successfully interpreted as valid video in the form of transmission and when decrypted using an appropriate key.) the system operator may pre-compute the compressed video sequences or portions (such as useful ciphertext blocks and corresponding keys) available in the sequence. The flows may be combined in real-time or in advance. For example, a normal sequence of video (such as a full black display) may be pre-computed and inserted. If the key check is performed by the decoding device, the system operator may need to perform a search to find multiple keys that may pass the same key check simultaneously. The search may be simplified using a collision search technique using birthday paradox (birthday paradox).

Although the bandwidth required for a video stream is typically increased for a video segment encoded as described above, the overall bandwidth impact can be minimized by limiting its use to situations where pirate attacks believed to require tracking are ongoing. If a pirate attempts to identify and delete video segments for which the present invention works (e.g., by analyzing the amount of data ignored in the stream), similar features can be placed in the normal (unmarked) areas to create "smoked herring" to interfere with the attacker.

For systems using ciphers with unused bits, such as parity bits typically included in single DES or triple DES keys, forensic information may be included in these bits, although the effectiveness of this approach may be limited if a pirate can rewrite the values in these bits before forwarding the key.

The logic for deriving the appropriate key value on the device should be implemented inside the secure device. Key derivation may be performed using software and/or rules received over the air (e.g., in encrypted form and intermingled with video or other content). For example, before transmitting blocks that can be decrypted in multiple ways, a system operator may transmit (individually and/or in groups) keys (or key-encryption-keys) such that a predetermined subset of the viewing base (viewing base) has each key. These keys may be used to decrypt or otherwise derive the appropriate video key on each device. The subset may be selected randomly and/or may be selected based on geographic location (e.g., based on the ability to receive spot beam satellite signals that are also used to transmit local television channels, location in the cable network, etc.), subscriber ID, phone number, knowledge of one or more keys, device type, or any other characteristic (or combination of characteristics). Executable code may also be delivered (optionally in real-time) to assist (or perform) key derivation/selection.

The specific steps and components involved in an exemplary embodiment for tracking the source of malicious redistributed keys and/or videos include any or all of the following steps (in any order): (a) creating a portion of compressed, encrypted video that when decrypted using each of two different key states produces at least two different plaintexts, and wherein each of the plaintexts can be correctly decoded into a valid portion of the compressed content stream; (b) transmitting control data to a plurality of conditional access apparatuses, wherein the control data is configured such that each of the conditional access apparatuses outputs one of the at least two keys; (c) receiving keys and/or video (and/or other data) forwarded by the malicious source that contain or correspond to one (or more) of the keys; (d) using knowledge of which keys are included in (or used to generate) the data of the malicious transmission to obtain information about the security module of the malicious source, for example by inferring that the malicious source has a means by which the received key (or video) can be derived; (e) repeating some or all of the above steps using increased awareness of pirate parties until at least one malicious device has been identified; and (f) disabling the malicious device, for example by sending a "delete" message or by rejecting to future keys.

Although the above examples are described primarily with respect to the video portion of audiovisual content, the same techniques are equally applicable to audio and other kinds of content.

Examples of attacks and countermeasures

This section describes certain exemplary attacks and countermeasures.

A pirate may try to disable the overlapping capabilities of the player to prevent overlap-based forensic marks from being embedded in the output. A counter measure to this attack is that the content owner directly embeds the markers in the compressed stream of audio-visual data.

A pirate may attempt to compare and combine the outputs from multiple devices in an attempt to remove the forensic mark. For example, in locations where the output of the device is different, a pirate may attempt to combine videos, delete/reduce the quality of videos, probabilistically select variants, select the most common variants, or use other techniques to make copies that are more difficult to track. If the number of collusion devices (clutters) is known to be quite small, the marker recovery process can exclude any group of collusion devices where no member is able to output the recovered marker by identifying the collusion devices using each marker. The content provider may also include forensic marks with many different variations (thereby making averaging and selection difficult). Highly visible forensic marks may also be used to obtain enhanced resistance to degradation or ambiguity caused by malicious attacks. Editing of subsequent content using improved forensic marking techniques may be required if necessary. Content owners can also embed a large number of marks and look for correlation between sequences embedded by individual devices and recovered copies.

A pirate may attempt to emulate a legitimate player. Related attacks involve modifying the interpreter in a legitimate player to operate in an incorrect (possibly malicious) manner. In this case, differences between the legitimate player and the emulation (including (without limitation) unrecorded operations, native code support, timing/performance, cryptographic keys, etc.) can be used to distinguish the legitimate environment from the malicious environment. Native code player updates may also be employed to correct vulnerabilities, for example.

A pirate may attempt to extract digital content by compromising a codec, device driver, display/speaker device, or other component that receives the content before or after decompression. Similarly, malicious versions of these or other components may be inserted. In response to the attack, the future content may respond by authenticating the output device and denying the provision of the content to the leaked device. The content may deliver a security upgrade (such as a local code patch) to a vulnerable or unknown device. Forensic marks may also be used to track copies that are leaked in this manner, providing a psychological and legal deterrent and a means of identifying pirates to revoke.

A pirate may attempt to "pre-record" the inputs and outputs of all TRAP operations and use this data for a malicious interpreter. This attack can be thwarted in a number of ways, including by using native code to over-measure the amount of storage space required, by using forensic marks to track leaks, or by upgrading the security of the original device. If the source device is not actually compromised (e.g., it is running malicious content code), then player cryptographic operations may be used to ensure that the player is actually running content code that is signed, decrypted, etc.

A malicious pirate may attempt to produce a hostile interpreter that operates incorrectly in a manner intended to circumvent security checks. A specific example is where a malicious interpreter attempts to subject content code to an invalid RSA signature, for example by searching for and replacing an expected computed intermediate value. To defeat the attack, the player may verify the signature using calculations other than simply taking the cube of the signature (taking the modulus of n) and comparing to expected values. For example, the content code may be multiplied by an initial value, then the verification result is equal to the cubic multiplication of the expected value and the initial value. Another way of verifying the signature involves adding a constant to the signature and then verifying that the result is correct. The signature verification code may also be mixed with other operations, such as modification of a symmetric cryptographic key, so that the resulting cryptographic value is correct only if the signature is valid. Self-modifying code, code obfuscation techniques, native code, and any other counter measures may also be used as appropriate.

A pirate may attempt to insert malicious firmware into a media interface, such as an optical disc drive. This attack can be detected by having the content code perform a self-check to authenticate itself and verify that the data was loaded correctly from the media. Native code and/or interpreted code may also be run by the driver to detect attacks. Content may also detect attacks by including data to be modified by the attack and detecting whether the data has changed.

A pirate may attempt to emulate the media (including security features), for example, by using a malicious device driver that loads data from files on the hard drive, rather than from legitimate media. This attack can be detected and thwarted by verifying that the driver has a valid cryptogra phic key. If the pirate finds a way to extract the key from a legitimate drive (thereby enabling a malicious emulator to emulate the cryptographic operations of a legitimate drive), additional drive authentication steps may be performed (such as providing native code for the drive, timing checking, testing non-standard functionality, etc.). In addition, malicious device drivers may be detected (e.g., using TRAP _ deviceicovery, native code, etc.).

Pirates may attempt to exploit vulnerabilities in the security code of a particular subject. While some counter measures may be possible (e.g., by passing updated security logic), the primary solution is for the content author to ensure that future content is edited more carefully and does not have the same vulnerabilities.

Additional considerations and variations

The media may be configured to allow a limited number of uses (e.g., any three music videos may be viewed) or duration of access (e.g., access rights expire 3 days after first viewing). The user may then be required to make payment to obtain authorization for further (or unlimited) playback. The viewing counter (and/or other security and status information) may be stored on the media itself and/or in the player and/or on a remote server. For example, data authorizing unlimited playback may be placed on a writable portion of the media, allowing playback on any player. Alternatively, the authorization may be stored in a non-volatile memory of the player and/or the content code may be configured to contact the server via a network to obtain the authorization.

Portions (or all portions) of the content on the media may be inaccessible until certain conditions are met (e.g., payment, playback of some combination of other topics, puzzle solving, some amount of time has elapsed, etc.). In one example, the content code is not functional until purchased or activated. The activation process may be performed locally or may involve interaction with a remote server. For example, the content code may contact a remote server, identify a local playback device to the server, interact with the user and the server to effect payment, and receive certain keys, interpretable security codes, or other data that allows decoding of the content. After the purchase is completed, the received data is used to activate the decoding of the content.

When a user purchases a new player, a provision may be included to allow migration of the player non-volatile memory from the old player to the new player. In an embodiment, this process is performed by moving data between devices on a physical carrier, such as a smart card or a writable medium. Alternatively, the transmission may be performed via a digital connection, such as a wired or wireless network or an infrared port. For maximum security, the transfer may be via (or mediated by) a trusted server device that communicates with the supplier device and the recipient device to ensure that the data is transferred correctly and is removed (or invalidated) on the supplier device before it is available on the recipient device. To accommodate data written by many different content themes, a single server may know how many themes use non-volatile storage, or the player may interact with multiple servers (e.g., as identified in the non-volatile memory slot itself). Cryptographic keys on the supplier and receiver may be used to provide security for the transfer.

The media may include a plurality of data encoding methods. For example, a single optical disc may include a high-density embossed portion, a write-once portion, and a recordable portion.

Location and distance measurement techniques may be used to ensure that recipient devices are not in an unacceptable physical location (such as in an unauthorized country, too far away from a home network server that provides content for home use only, etc.). Round trip communication (round communication) round trip time may be multiplied by the speed of light to determine the upper range limit to the device. Global positioning systems and attenuation of radio signals (e.g., if the device is within the range of 802.11b specifications, bluetooth technology, etc., or if the device has access to ordinary radio/satellite signals, etc.) may also be used to estimate location and/or proximity. The ability of the devices to share a common wire (telephone connection, power circuit of the home, etc.) may also be used. The internet IP address and telephone number may also be used to obtain location information (e.g., for regional encoding applications, regional sports signalization, selection of default language/currency unit options). The location information may be included in the forensic mark.

The player may provide a volatile or "fragile non-volatile" memory storage area, such as a memory slot that allows the content to transfer data to the next disc inserted but deletes the content immediately thereafter. Volatile memory can be used for temporary storage in situations where it is irrelevant whether the contents are erased when power is removed.

A network of neurons may be used in forensic marker detection/analysis to define an optimal security policy, and so on.

The content code may be configured to allow playback from the recordable medium in the presence of correct authentication. For example, this capability can be used to create a compact disk burning kiosk (or other system) that can record media for consumers, e.g., to allow smaller stores to meet unpredictable consumer needs without having to maintain a larger inventory. The kiosk may retrieve the (original) content from any source or combination of sources, including internal storage (hard disk, etc.) and data networks. The recorded data may be modified by the kiosk (using an interpretive code running in an interpreter included in the kiosk as appropriate), for example, to introduce identification of forensic marks, re-encryption of portions of the data, associating up-to-date security logic with the content, combining multiple content portions selected by the consumer, accommodating user requests/preferences, compressing (re-compressing) the content or changing formats to meet capacity or codec requirements of the media or player device, and so forth.

A value to cryptographically authenticate the recording and authorize playback may also be included. This may be, for example, a digital signature issued by a trusted party, communicated to a kiosk over a network, burned on a media, and verified by the content code during playback. This digital signature may, for example, include a media identifier, the root of the hash tree of the content computed using SHA-1, an identifier of the kiosk's recording drive, the release date, and the serial number of the target media.

The information station may also include: an interface for receiving tickets, credit cards or other payments; a touch screen or other input device for receiving user selections; the ability to print customized box liners, media surfaces, receipts, and the like; network capabilities for retrieving new content data, receiving new user interface components and advertising/quotations, checking and processing payments, reporting error conditions, and the like; and audio/video manipulation capabilities for converting data into a desired output format, creating customized menus, and the like.

To achieve high performance when writing physical media, such as optical discs, a media recording device may use multiple recording lasers simultaneously. A physical support shield may be provided around the media to prevent vibration or damage due to centrifugal forces. Mirrors or other optical elements may be used to move the laser beam around the medium to reduce or eliminate the need to physically rotate the optical medium. Recording may be performed using non-laser based recording techniques (such as by providing micro-droplets of an etching substance on a circular substrate, for example using high resolution techniques similar to those used in inkjet printers, followed by coating the substrate with a protective layer).

The media need not be physically present at the playback device. For example, media may communicate with a player device via a wireless network or other network. In one embodiment, the medium includes a coil and at least one semiconductor chip configured to (a) receive power from the induction coil; (b) using an induction coil to send and receive data with a player (or other device); (c) retrieving content (including content code, if supported) from local memory, which may or may not include a writeable section; (d) a cryptographic "handshake" is performed for use by the content code or other device to authenticate the validity of the media. If there can be multiple such media (e.g., contained in an optionally removable tray in a player device that can contain multiple media), an addressing method can be used to allow selection of which media should be communicating at a given time.

The content code may interact with any manner of external device and with components (such as software programs) that may be included in the player device. For example, a smart toy (or other device) may interact with content code that supports the device (or a broad class of the devices). The interaction may include any manner of data exchange, including commands (e.g., direction of toy vehicle movement), audio data (e.g., sounds emitted by the device, sounds recorded by the device, etc.), image/video data (e.g., for display by the device, from a digital camera in the device, etc.), logic (e.g., for execution by the device), event notification, and so forth. In one embodiment, the content code interacts with and helps control external devices and devices, including (without limitation) lights, heaters, air conditioners, home security systems, appliances, pet care/feeding devices, video recorders, and the like. The method of communication between the player device and the external device may include outputting data from the player device via a conventional audiovisual output (e.g., to a microphone, CCD, or other sensor on a remote device) and receiving data via a remote control (e.g., infrared) interface. Other supported communication methods may include wireless and wired networks and data exchange protocols. Some player devices may not have the interface necessary to enable all desired external interactions, in which case the external interface module may be connected directly (e.g., via a physical interface that conducts bidirectional data communication and power supply). The external device may also include non-volatile memory or other storage for carrying code (including interpreted code) for delivery to the player device, e.g., to assist the player device and/or content code in using features provided by the external device.

Aspects of the playback system may be implemented separately and may communicate with each other. For example, on certain platforms (such as personal computers), it may be advantageous to separate the portion that implements the discovery and/or security assessment capabilities from the main player application, as these components may require more frequent updates than other components. In an exemplary implementation, the content code communicates with a security scanner configured to detect known security issues such as the presence of malicious, unauthorized, and/or suspicious software. The scanner also provides information to the content code and/or player application regarding the state of the system, such as which applications are running, which device drivers are installed, which devices are known to be connected, and so forth. The scanner may also report its assessment of the security status of the current system, such as whether the system meets the requirements for secure playback. Because new piracy risks may quickly arise, for example if a new software vulnerability is disclosed, it is preferable to make frequent updates to the scanner program, such as by downloading updates via the internet or receiving digitally signed updates delivered with the content code. The user may be charged for the update service (e.g., by automatically and periodically collecting payment credentials corresponding to the user, automatically notifying the user whether the payment was unsuccessful, and/or automatically terminating the user's access when payment is not ultimately received). The scanner may also notify the user of its results, automatically correct problems, and/or automatically download countermeasures or updates. The scanner may also notify the content code or other component of the change in system/security status, for example, by registering an interrupt or event. Communications between components, such as between content codes and scanners, may be cryptographically secured. For example, the scanner may digitally sign its results along with the challenge value to prevent replay attacks. The scanner may be integrated with an anti-virus scanner or other vulnerability scanner, although its functionality differs from conventional virus detectors by: it provides cryptographic authentication of its results as proof of the state of the machine as it is available to the content owner, rather than just protecting the interests of the owner or operator of the computer.

An automated program may also be configured to search a computer to detect unauthorized (e.g., pirated) content. If the content is found, the program may notify the user of the potentially infringing material. The program may also interact with (and provide proof to) the content code or other security component, for example, to authorize playback of the content on a device believed to be free of pirated material. To determine whether the material is authorized, the scanner may look for a license file, a digital signature, a hash of a known file, and so forth.

The elements of the present invention (including the security and non-security features) may be used (without limitation) with non-programmable content distribution systems, with content protection systems that use native code rather than an interpreter or virtual machine, as part of any software application or device, on programmable systems that always run code locally (as opposed to processing using an interpreter/virtual machine), and in other systems (including electronic gaming machine copy protection and security systems). By way of example and not limitation, individual aspects may be used for computer security applications, network security applications, non-programmable anti-piracy systems, fraud screening systems, e-mail filtering, and so forth.

The present invention may be incorporated with digital data broadcasting systems including (without limitation) all kinds of television broadcasts, satellite transmissions, communications over cable networks, internet multicasting, and the like. The broadcast signal may carry code (including security-related information and countermeasures) for use with the content or other content carried in the signal. The broadcast signal may also carry content and/or other data that may be used by other content topics. Security capabilities may also be integrated with (and in communication with) conventional conditional access cards and systems for protecting television signals.

When the components of the present invention interact, they may use cryptographic techniques to secure their communications. The security features may include the use of symmetric encryption and/or message authentication codes (or other checks) on the data. Public key cryptography (including digital signatures/certificates, exponential key protocols, public key encryption/decryption, challenge-response protocols, etc.) may be used to negotiate symmetric keys for protecting the communication, or asymmetric cryptography may be applied directly to the data. Revocation status of symmetric and asymmetric keys may be enforced (e.g., by checking revocation lists, interacting with remote servers, etc.). Keys may also be negotiated using symmetric cryptographic protocols, including (without limitation) using broadcast encryption techniques. The security measures used need not be the same for all communications. (for example, control messages, security-related parameters, keys, and/or MPEG "I" frames may be encrypted while other communications may not be encrypted.) the keys used to protect the "handshake", including one or more related certificates related to each key or set of keys, may be verified using the content code and/or directly by the device. Examples of components whose communications may be suitably cryptographically protected include (without limitation): optical disk drives, other media interfaces, media interface device drivers, player applications, content code execution threads (e.g., from a different content subject being run simultaneously or from another thread belonging to the same content subject), operating systems, video device drivers, video processors (or video cards, etc.), audio device drivers, audio processors, any manner of external device (whether locally connected, accessed via a network, accessed via a bus, etc.), other applications (security scanners, audio mixers, video effects processors, etc.), codecs, and security modules.

Digital signatures may also be generated using keys authenticated using one or more certificates, and may be combined with other security values. Multiple versions of a signature (e.g., generated with different keys/signers, key sizes, algorithms, etc.) may be provided.

The examples should not be construed as imposing limitations. Lists are not necessarily fully enumerated for the sake of brevity, particularly where items are included in similar lists. The word "comprising" means including without limitation. Similarly, "such as" and "for example" mean illustrative examples that do not limit the generality of the thing being discussed. Similarly, "and the like" means that there are additional possibilities, and the list should not be construed as necessarily listing all known possibilities.

In an exemplary embodiment, the content may be customized for a particular player. In this case, the content can only be played on a single player or a few players, but code that is not needed for playback on the recipient device need not be transmitted. This approach is therefore particularly valuable when it is difficult, expensive or slow to send information to the user, for example if there is a limit to storage space or if content must be sent over a slow network connection. However, the content may still query the player to verify that the playback environment is properly secure.

To ensure that playback is not interrupted or distorted, it may be useful for the interpreter of the player to require specific minimum performance criteria.

In an exemplary embodiment, the system and method may be configured to allow content to be exchanged from one device to another. The specific security features of the exchange depend on factors such as whether online communication with a trusted (e.g., operated by a publisher) server is available. The form in which the content is delivered depends on the security policy enforced by the content and the hardware capabilities of the device. For example, in an embodiment where both devices include a secure interpreter, the sending device transmits the original encrypted content (as stored on the original media or encrypted with another key, optionally including a watermark) along with code for controlling playback. The playback control code may be customized by the sending device for the recipient device. In another case, the sending device may verify that the security features of the output port and the target device are acceptable, negotiate a shared key with the target device, decrypt and watermark the content, re-encrypt the content using the shared key, and send the re-encrypted content to the target.

A player with sufficient non-volatile storage space may be used to store the updateable code called from the interpreter. For example, the player may be configured to always store the latest security code for a particular publisher. In this case, if a newer version of the security code is encountered, the old version will be updated (e.g., after checking the digital signature on the new code). In this way, older content may benefit from a secure update carried over new content. (this approach may be implemented, for example, using the secure memory approach described above.) in another embodiment, the content may require the player to include a current security update by obtaining the current date/time from the player and comparing it to the date/time of the last known security upgrade. In this way, the content can ensure that the player has reasonably up-to-date security upgrades.

Generally, a content protection system should avoid playing any visible role in the legitimate actions of legitimate users. However, certain user interface elements are necessary, such as for reporting errors or providing information. In situations where content may be selected between multiple supported output qualities (e.g., "legacy" quality when the player provides insufficient security and "high" quality when the security is satisfactory), an indicator may be used to inform the user of the quality of the output. For example, in an embodiment, a green Light Emitting Diode (LED) controlled by the content indicates that the output is of high quality (i.e., security is satisfactory), an orange LED indicates reduced quality (i.e., security is not high), and a flashing red LED may indicate that no output is provided because the player has been deactivated. In another embodiment, a brief verbal or written notification (in the user's language, if known) is provided to report the status of the security. The decision to report and/or use a higher quality output or a lower quality output may be based on other factors, such as the presence and/or absence of robust and/or fragile watermarks. If desired, a quality reduction module may be included in the player to allow the content to reduce the quality of playback (e.g., to a legacy format) for security or other reasons. (for example, a quality reduction module may be included to convert a high definition television signal to NTSC resolution or high resolution multi-channel audio to two-channel CD quality audio.)

Bulk decryption and watermark embedding may be handled in the interpreter instead of in a separate decryption module if the media interface and player interpreter provide sufficient performance. Allowing the content to decrypt itself directly may provide several security benefits, such as ensuring that an attacker does not launch an attack against the decryption module. It is also possible to implement content decompression also in the interpreter if the interpreter performance is sufficient, thereby avoiding the need to standardize single player codec types.

While the implementation using an interpreter is preferably on a platform (such as a personal computer) that does not have specific hardware support for the techniques and systems disclosed herein, it is possible to implement many interpreter functions in dedicated hardware. Depending on the application, while dedicated implementations provide reduced functionality, they may save cost or power consumption.

Embodiments that receive content on physical media may use virtually any media format. While optical discs (such as CDs and DVDs) provide higher storage densities at lower cost, other storage systems may be used, including (without limitation): magnetic media, holographic memory, battery backed RAM, ROM, EEPROM, and flash memory. The storage capacity of the media may be used to store many different types of data, including information related to the techniques and systems disclosed herein (such as executable programs that implement decoding methods for various computer platforms, content protected using the methods disclosed herein, etc.) as well as data not directly related to the techniques and systems disclosed herein (such as unrelated executable programs, unprotected content such as redbook CD audio, content protected using other security schemes, etc.).

The media may include tamper-resistant circuitry for performing cryptographic calculations to allow the player to verify that the media is not an unauthorized copy. Even optical media may include cryptographic capabilities, although it is simplest to perform the capabilities for media using an electrical interface. For example, a contactless cryptographic module, such as the contactless smart card of U.S. patent 5,640,306 to Gaumet et al, may be affixed to or embedded in an optical disc. While cryptographic media authentication is preferred, other authentication mechanisms may be used instead. For example, a general media authentication method known in the background art includes: sequence numbers are written to locations that are difficult to copy (such as areas that are not writable using commercial recordable media or drives) and "descriptions" of digital signatures that include various characteristics of the original physical media. Of course, the cryptographic mechanism provides the following advantages: even if an attacker discovers a method for compromising existing media, future media with improved security can be released without requiring any changes to the player.

Because many consumers have invested in content in legacy formats, players implementing the techniques and systems disclosed herein may be configured to support these legacy formats. Similarly, different versions of the interpreter may be supported by a particular player. In this case, the player needs to analyze the media or content to identify the appropriate security system to use. For example, the digital video player may detect whether the disc is a legacy DVD that uses CSS (and if so, selects a CSS decryption system) or a DVD that uses the techniques and systems disclosed herein (and if so, activates a language-based decryption system). A robust watermark included in the content may be used to detect whether the content that was originally protected using a security system has been copied to a format that lacks the original protection. For example, content that is not allowed to be copied may include a watermark to indicate that any device that encounters a copy in any other format (e.g., in an unprotected format) may recognize the copy as unauthorized and, for example, deny playback.

The techniques and systems disclosed herein may be used with a wide variety of content types including, without limitation, audio, still images, video, three-dimensional images, and three-dimensional video.

The techniques and systems disclosed herein may also be implemented in a variety of physical devices. It is preferable that security policies be enforced by only one device if that device is responsible for decrypting the content. However, output devices and intermediate processing devices (such as audio equalizers or mixers) may also benefit from and/or verify the security of the techniques and systems disclosed herein by providing query capabilities that may be used by the techniques and systems. In an embodiment, the home entertainment server downloads, stores, and manages content, and forwards the content to a playback device (speaker, headphones, video display, etc.) that has successfully verified its security. The techniques and systems disclosed herein preferably encrypt connections to target devices under joint control of these devices to prevent content from being stolen in transit.

Claims (11)

1. A digital optical disc medium comprising encrypted audiovisual content for playback on any one of a plurality of playback environments, the digital optical disc medium comprising program logic configured to:

(a) identifying at least one characteristic of a device executing the program logic;

(b) using the at least one characteristic to determine which, if any, of a plurality of security vulnerabilities are present in the execution means;

(c) when the decision indicates a suspected vulnerability,

(i) selecting at least one of a plurality of software countermeasures, wherein the selected countermeasure corresponds to the suspected vulnerability and is compatible with the executing device;

(ii) mitigating the suspected vulnerability by controlling the performing means to invoke the selected counter-measure; and

(iii) decoding said encrypted audiovisual content, wherein said decoding comprises a value resulting from a successful operation of said counter-measure; and

(d) when the determination does not indicate a suspected vulnerability, decoding the audio-visual content using at least one decryption key derived using at least one cryptographic key associated with the execution device.

2. The dvd medium of claim 1, wherein said program logic is configured to execute in an interpreter that is common to said plurality of playback environments, and at least a portion of said selected counter-measure is configured to execute directly as native code on a microprocessor associated with said execution device.

3. The DVD medium of claim 2, further comprising a digital signature identifying a portion of the local code.

4. The DVD media of claim 1, wherein the program logic is further adapted to cryptographically authenticate at least one manufacturer, model, and version of the device executing the program logic.

5. The DVD medium of claim 1, wherein the program logic is adapted to verify that the device is capable of block cipher operation using at least one of a manufacturer, model, and version of the device as the at least one characteristic of the device.

6. The DVD medium of claim 1, wherein the program logic is adapted to verify that unauthorized firmware is present on the device as at least one characteristic of the device.

7. The dvd medium of claim 1, wherein the program logic is configured to access a server on a network and receive data from the server, the data representing at least one of: codes configured to recognize new features, codes to implement counter measures, cancellation status, payment information related to content, bonus content download, and advertisement download.

8. The DVD medium of claim 1, wherein the program logic is configured to identify a characteristic by looking for a portion of the memory of the device.

9. The dvd medium of claim 1, wherein the program logic is configured to recognize a characteristic by accessing a non-volatile memory portion of the device.

10. The dvd medium of claim 1, wherein the program logic is further configured to render the video replayable by applying a plurality of modifications to the video data stream.

11. The digital versatile disc medium of claim 10, wherein the program logic is further configured to cause the audiovisual content to change upon application of the plurality of modifications, such that the information in question relating to the playback environment is embedded.