US20020032903A1 - Authorization using ciphertext tokens - Google Patents

Abstract

According to the invention, a method for securing a plaintext object within a content receiver is disclosed. In one step, a secure portion of a secure object and a plaintext remainder of the secure object are received. Which portion of the secure object is the secure portion is determined. The secure portion is decrypted to provide a plaintext portion. The plaintext object that comprises the plaintext portion and the plaintext remainder is formed. The plaintext object is stored.

Description

• This is a continuation-in-part of U.S. application Ser. No. 09/580,303 filed on May 26, 2000.[0001]
BACKGROUND OF THE INVENTION
• This invention relates in general to secure access systems and, more specifically, to securing information in content receivers associated with conditional access systems.[0002]
• Cable television (TV) providers distribute video streams to subscribers by way of conditional access (CA) systems. CA systems distribute video streams from a headend of the cable TV provider to a set top box associated with a subscriber. The headend includes hardware that receives the video streams and distributes them to the set top boxes within the CA system. Select set top boxes are allowed to decode certain video streams according to entitlement information sent by the cable TV provider to the set top box. In a similar way, other video program providers use satellite dishes to wirelessly distribute video content to set top boxes.[0003]
• Video programs are broadcast to all set top boxes, but only a subset of those boxes are given access to specific video programs. For example, only those that have ordered a pay per view boxing match are allowed to view it even though every set top box may receive encrypted data stream for the match. Once a user orders the pay per view program, an entitlement message is broadcast in encrypted form to all set top boxes. Only the particular set top box the entitlement message is intended for can decrypt it. Inside the decrypted entitlement message is a key that will decrypt the pay per view program. With that key, the set top box decrypts the pay per view program as it is received in real-time. Some systems sign entitlement messages.[0004]
• Only recently has storage of multiple hours of video become practical. Each video program is transmitted to set top boxes as a compressed MPEG2 data stream. One hour of video corresponds to about one gigabyte of compressed data. Since multigigabyte storage is common today, multiple hours of video can now be stored. In contrast, conventional CA systems presume content is ephemeral and cannot be stored. In other words, conventional systems are designed presuming that the video programs were too large to retain them for any period of time. As those skilled in the art can appreciate, the ability to store multigigabyte video programs spawns a need for additional security measures in CA systems.[0005]
• Some systems integrate personal computing with a TV to display content. Products such as WebTV™ integrate web browsing and e-mail features with a TV. In other systems, a personal computer (PC) is connected to an Internet service provider (ISP) that provides the content for the web browsing and e-mail features. Software programs, such as the e-mail program, tend to be small and easily stored. Those skilled in the art recognize that these PCs do not provide adequate security such that they are susceptible to viruses and hackers.[0006]
• As described above, conventional CA systems only check entitlement of video streams. With advent of larger storage and smaller Internet related programs, content can be stored and reside with the user for an indefinite period of time. To maintain control over this content, additional security measures are needed.[0007]
BRIEF DESCRIPTION OF THE DRAWINGS
• The present invention is described in conjunction with the appended figures:[0008]
• FIG. 1 is a block diagram showing one embodiment of a content delivery system;[0009]
• FIG. 2 is a block diagram illustrating an embodiment of a set top box interfaced to its environment;[0010]
• FIG. 3 is a flow diagram showing an embodiment of a process for distributing an object in a first security level;[0011]
• FIG. 4 is a flow diagram showing an embodiment of a process for distributing an object in a second security level;[0012]
• FIG. 5 is a block diagram depicting an embodiment of an authorization message;[0013]
• FIG. 6 is a block diagram showing an embodiment of a software message;[0014]
• FIG. 7 is a block diagram illustrating an embodiment of a signatory group that includes portions of the authorization message and the software message;[0015]
• FIG. 8 is a block diagram showing an embodiment of a “rights” message;[0016]
• FIG. 9 is a block diagram illustrating an embodiment of interaction between functional units;[0017]
• FIG. 10 is a flow diagram depicting an embodiment of a process for loading an object in a third security level;[0018]
• FIG. 11 is a flow diagram showing an embodiment of a process for loading an object in a fourth security level;[0019]
• FIG. 12 is a flow diagram depicting another embodiment of a process for loading an object in the fourth security level;[0020]
• FIG. 13 is a flow diagram showing an embodiment of a process for checking continuously running objects in a fifth security level;[0021]
• FIG. 14A is a flow diagram illustrating an embodiment of a process for allowing a free preview of an object in security level six;[0022]
• FIG. 14B is a flow diagram illustrating another embodiment of a process for allowing a free preview of an object in security level six;[0023]
• FIG. 15A is a flow diagram showing an embodiment of a process for monitoring reports back to a headend in security level seven;[0024]
• FIG. 15B is a flow diagram showing an embodiment of a process for monitoring security checks in security level seven;[0025]
• FIG. 15C is a flow diagram showing another embodiment of a process for monitoring security checks in security level seven;[0026]
• FIG. 16A is a flow diagram of an embodiment of a process for producing partially-encrypted objects in an eighth level of security;[0027]
• FIG. 16B is a flow diagram depicting an embodiment of a process for using execution tokens to achieve the eighth level of security;[0028]
• FIG. 16C is a flow diagram depicting an embodiment of a process for using partial download to achieve the eighth level of security; and[0029]
• FIG. 17 is a block diagram showing the relationship between different objects in a set top box.[0030]
DESCRIPTION OF THE SPECIFIC EMBODIMENTS
• The ensuing description provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the invention. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment of the invention. It being understood that various changed may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set for in the appended claims.[0031]
• The present invention uses ciphertext tokens to enhance authorization in a television (TV) set top box. An object is stored in two portions where one portion is inaccessible before authorization. Decryption can be used to make the one portion inaccessible. The set top box decrypts the one portion after authorization to reformulate and use the object.[0032]
• In the Figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.[0033]
• Referring first to FIG. 1, a block diagram of one embodiment of a[0034]content delivery system100 is shown. Thedelivery system100 selectively provides content to a number of users based upon certain conditions being satisfied. Included in thesystem100 are aheadend104, number of settop boxes108,local programming receiver112,satellite dish116, and theInternet120.
• The[0035]headend104 receives content and distributes that content to users. Content can include video, audio, interactive video, software, firmware, and/or data. This content is received from a variety of sources that could include thesatellite dish116, thelocal programming receiver112, a microwave receiver, a packet switched network, theInternet120, etc. Each settop box108 has a unique address that allows sending entitlement information to an individualset top box108. In this way, one set top box108-1 might be entitled to some particular content while another108-2 might not. Equipment within theheadend104 regulates the subset of settop boxes108 are entitled to some particular content.
• The content is generally distributed in digital form through an analog carrier channel that contains multiple content streams. All the content streams are multiplexed together into a digital stream that is modulated upon the analog carrier channel. The separate content streams are tracked by packet identification (PID) information such that the individual content streams can be removed according to their unique PID information. There are around one hundred and twenty analog carrier channels in this embodiment of the[0036]system100. Other embodiments could distribute the content with transport mechanisms that include satellite dishes, microwave antennas, RF transmitters, packet switched networks, cellular data modems, carrier current, phone lines, and/or the Internet.
• Referring next to FIG. 2, a block diagram of an embodiment of a[0037]display system200 is shown. This embodiment provides multiple levels of object and resource security through a variety of security mechanisms. Included in thedisplay system200 are a settop box108,network208,printer212,TV display216, andwireless input device218. These items cooperate in such a way that the user can enjoy content conditionally distributed by a content provider. The content can include video, audio, software, firmware, interactive TV, data, text, and/or other information. In this embodiment, the content provider is a cable TV provider or multiple system operator (MSO).
• The[0038]network208 serves as the conduit for information traveling between the settop box108 and theheadend104 of the cable TV provider. In this embodiment, thenetwork208 has one hundred and twenty analog channels and a bi-directional control data channel. Generally, the analog channels carry content and the control data channel carries control and entitlement information. Each analog carrier channel has a number of digital channels multiplexed into one data stream where the digital channels are distinguished by packet identifiers (PIDs). The bi-directional control channel is an out-of-band channel that broadcasts data to the settop boxes108 at one frequency and receives data from theboxes108 at another frequency. Return data may be queued to decrease overloading during peak use periods using a store-and-forward methodology well known in the art. Other embodiments could use a cable modem, digital subscriber line (DSL), cellular data, satellite links, microwave links, carrier current transport, or other network connection for both control information and content where the content is formatted as packet switched data.
• The[0039]printer212 is an optional accessory some users may purchase and add to theirdisplay system200. When using the settop box108 for personal computer tasks, theprinter212 allows printing data such as email, web pages, billing information, etc. As will be explained further below, the ability to use a peripheral such as a printer is regulated by an authorization check. Using this regulation feature,printers212 compatible with the settop box108 do not work unless proper authorization is obtained to enable thatprinter212 for that settop box108.
• The[0040]TV display216 presents the user with audio, text and/or video corresponding to the content. Thedisplay216 typically receives an analog video signal that is modulated on a carrier corresponding to channel three, channel four or a composite channel. The settop box108 produces a NTSC signal, for example, modulated to the appropriate channel. Other embodiments could use a video monitor or digital display instead of atelevision display216. Use of a digital display would alleviate the need for an analog conversion by the settop box108 because digital displays, such as liquid crystal displays, use digital information to formulate the displayed picture.
• The[0041]wireless input device218 allows interaction between the user and the settop box108. Thisdevice218 could be a remote control, mouse, keyboard, game controller, pen tablet or other input mechanism. An infrared transceiver on theinput device218 communicates with a similar transceiver on the settop box108 to allow wireless communication. In other embodiments, RF link or wired link could be used instead of the infrared transceiver.
• The set[0042]top box108 has component parts that perform authentication and authorization of objects and resources. Objects are any collection of digital information such as software, drivers, firmware, data, video, or audio. The software could include a software program(s) and/or a software dynamic link library or libraries. Resources are anything needed by an object to operate as intended such as another object or a physical device. Included in the settop box108 are acontroller220,memory228, aprinter port232, anetwork port236, anaccess control processor240, adisplay interface244, and an infrared (IR)port248. These blocks communicate with each other over abus230 where each block has a different address to uniquely identify it on thebus230. Typically, the settop box108 is a separate device, but could be integrated with theTV display216, a computer, an information appliance, or personal video recorder (PVR).
• The[0043]controller220 manages operation of the settop box108 using a trusted or secure operating system. Such functions as digital object decryption and decompression are performed in thecontroller220 as well as functions such as switching TV channels for the user and presenting menus to the user. Included in thecontroller220 are a processor, an encryption engine, local memory, and other items common in computing systems.
• In other embodiments, the[0044]controller220 could also contain an adjunct secure microprocessor for purposes of key protection or cryptographic processing. This may be appropriate in some systems where a high level of security is desired.
• The set[0045]top box108 includes a block ofmemory228. Thismemory228 is solid state memory that could include RAM, ROM, flash, and other types of volatile and non-volatile memory. Objects and resources are stored in memory for running at a later time. During execution, programs are loaded into and executed within thememory228, and also use thememory228 for scratchpad space. Keys, serial numbers and authorizations can be stored in non-volatile flash memory.
• This embodiment includes a[0046]printer port232 for interfacing to anoptional printer212. Theprinter port232 resource is not available to programs unless authorized. As explained further below, each object must have authorization to use a resource such as theprinter port232. Data is sent from theprinter port232 to theprinter212 in a serial or parallel fashion by way of a wired or wireless transport mechanism.
• Stated generally, a checkpoint is a point in time or a step of processing where the authentication and/or authorization status of a functional unit is confirmed. A checkpoint is encountered when printing is requested. The checkpoint authorizes and authenticates the object requesting the printing. Checkpoints are places in one object where authentication and/or authorization are run on another object (e.g., an operating system checks authentication and authorization of an application that is running). Ideally, checkpoints are performed when the purpose of the object becomes manifest. In the case of a[0047]printer port232, its purpose becomes manifest when it is used to print something. Accordingly, a checkpoint is triggered to check the object using theprinter port232 resource when anything is printed. Typically, the checkpoint for printing would be in the operating system.
• Other types of objects would have other purposes that would correspond to a checkpoint so as to require authentication and/or authorization when the purpose becomes manifest. For example, an object may be stored in long-term memory. Reading the object from long-term memory would trigger a checkpoint. When the object is loaded into short-term solid-state memory, another checkpoint is encountered. A new signature may be calculated when the object is moved from long-term to short-term memory. Whenever the object is read from short-term and processed by the[0048]controller220, another checkpoint may be encountered. Further, another checkpoint may be encountered if the object is displayed on a screen or played through speakers. Various embodiments could have one or more of these checks performed at different stages of processing by the settop box200.
• The[0049]network port236 allows bi-directional communication between the settop box108 and theheadend104. Included in thenetwork port236 are a tuner and a demodulator that tune to analog carrier channels and demodulate an MPEG data stream to allow one-way delivery of content. Also included in thenetwork port236 is a control data transceiver or cable modem that allows for bi-directional communication of control data information and/or content. To distribute loading of the control data path to theheadend104 more evenly, a store and forward methodology may be used.
• Modulation of the digital video signal onto an analog signal compatible with the[0050]TV display216 is performed by thedisplay interface244. As discussed above, theTV display216 generally accepts signals modulated on channel three, channel four or a composite channel. For displays that accept a digital input, such as LCD displays, thedisplay interface244 performs any formatting required by the digital input.
• The[0051]IR port248 communicates bi-directionally with awireless input device218. Included in theIR port248 is an IR transceiver that provides the wireless communication path with theinput device218. Other electronics in theIR port248 convert analog signals received by the transceiver to a corresponding digital signal and convert analog signals sent to the transceiver from a corresponding digital signal. Thecontroller220 processed the digital signals so that the user can control some of the functions within the settop box108.
• The access control processor (ACP)[0052]240 regulates security functions within the settop box108. For example, theACP240 performs authentication and authorization either under the direction of thecontroller220 or independent of thecontroller220 as will become clear in the discussion below. To perform its tasks, theACP240 includes a processor, RAM and ROM that cooperate to execute software independent of thecontroller220. TheACP240 also includes a decryption engine and a hash function for deciphering content and calculating signatures. Checkpoints are embedded into the software run that trigger theACP240 to perform security checks. In this embodiment, theACP240 is implemented in hardware, but other embodiments could perform the functions of theACP240 in software.
• The[0053]ACP240 can also shadow the operating system (OS) to assure proper functioning of the OS. By watching the launch of objects, theACP240 can monitor which application objects are running. If necessary, theACP240 can kill or stop execution of running applications if a checkpoint detects an error or if authorization expires. Further, theACP240 could monitormemory228 to detect any application not authorized to be inmemory228. Scratchpad memory size could also be monitored to detect applications hiding in scratchpad memory. Additionally, theACP240 could randomly execute checkpoints on the objects inmemory228 to confirm their authorization and/or authenticity. Problems encountered by theACP240 are reported to either the OS or theheadend104. In these ways, theACP240 acts as a software security guard bot within the settop box108 such that aberrant behavior is detected and reported.
• Referring next to FIG. 3, a flow diagram of an embodiment of a process for distributing an object in the first security level is shown. The process begins in[0054]step304 where an entitlement message is formulated in theheadend104. Included in the entitlement message is a key that can decrypt the associated object. Instep308, the entitlement message and object are sent over thenetwork208 to the settop box108. After receipt of the entitlement message and object, they are correlated together instep316. The key is extracted from the entitlement message and used to decrypt the object before it is written to thememory228 insteps320,324 and328. This process provides both authentication and authorization of the object by using encryption.
• In some embodiments, the keys are loaded into the set[0055]top box108 in a controlled environment before shipping thebox108 to the consumer. For example, symmetric or asymmetric keys are loaded into the settop box108 during assembly at the factory. There could be unique or global keys stored in eachbox108 to allow secure multicast or singlecast of content over an encrypted channel. This channel could be used to later add, delete or change keys. The MSO by use of the keys can control access to content without the need for interaction with the user.
• Referring next to FIG. 4, a flow diagram of an embodiment of a process for distributing an object in a second security level is shown. In the second level of security, signatures are used to authenticate an object upon download. In other words, the second level of security imposes a checkpoint on the object when downloaded. The signature is generated over a signatory group that includes portions of an authorization message and object message in the[0056]headend104 in step404. The authorization message is meta-data related to the object message and the object message contains the object intended for the settop box108.
• In[0057]step408, the signature in the authorization message and the object are separately sent to the settop box108 over thenetwork208. Preferably an asymmetric signature is used (e.g., RSA, DSA or ECC based), but a symmetric signature (e.g., DES or triple-DES) could also be used. Upon receipt of the signature and the object and before storing the object, the signature is calculated and checked by theACP240 insteps420 and424. If the calculated and received signatures match, the object is stored instep428. Alternatively, the object is discarded instep432 if there is no match, and processing loops back to step412 to wait for another copy of the object.
• With reference to FIGS.[0058]5-7, anauthorization message500, asoftware message600 and asignatory group700 are respectively shown in block diagram form. Included in theauthorization message500 of FIG. 5 are anauthorization header504, anauthorization data structure508, a signature(s)512, and afirst checksum516. Theauthorization message500 has information used to both authenticate and authorize thesoftware message600. Forming the software message of FIG. 6 are anobject header604, asoftware object608 and asecond checksum612. Thesoftware message600 serves as the transport for thesoftware object608. Thesignatory group700 includes components of theauthorization message500 andsoftware message600 arranged end-to-end. More specifically, thesignatory group700 of FIG. 7 includes theauthorization header504,authorization data structure508,object header604, andsoftware object608. Thesignature512 is calculated over thewhole signatory group700.
• The[0059]authorization header504 indicates the configuration of theauthorization message500. Included in theheader504 are a subtype identifier and message version. The subtype identifier distinguishes the various types ofauthorization messages500 from one another. In this embodiment, there are authorization message subtypes corresponding to software objects and resources. Software object subtypes have acorresponding software message600, but resource subtypes do not. Accordingly, the subtype identifier is used to determine if there is asoftware message600 associated with anauthorization message500. There may be several types of software object subtypes and resource subtypes for a given system and the message version allows distinguishing the various types.
• The[0060]authorization data structure508 provides requirements for a functional unit to the settop box108. A functional unit is either a software object or a resource. In the case of an authorization message subtype corresponding to a software object, theauthorization data structure508 contains an object or functional unit identifier, a software version, cost information, entitlement information, lifetime information, and one or more program tiers. The object identifier is unique for eachsoftware object608 and allows attributing anauthorization message500 to itscorresponding software message600. Version information is included in thedata structure508 to indicate the version of thesoftware object608.
• Portions of the[0061]authorization data structure508 are used to determine availability of thesoftware object608 to the settop box108. The cost information indicates to the settop box108, and sometimes the user, the price associated with thesoftware object608. Entitlement information is used to determine if the particularset top box108 is authorized to accept thesoftware object608. The entitlement information may include a key if thesoftware object608 is encrypted with a symmetric key. If the settop box108 is not authorized for thesoftware object608, there is no need to process thecorresponding software object608 when it is received. Lifetime information allows expiring of the authorization of thesoftware object608 to prevent use after a certain date or time. Programming tiers are used to restrict authorization of software objects608 to predefined tiers such that a settop box108 can only access software objects608 within a predetermined tier(s).
• The[0062]signature512 is used to verify that portions of both theauthorization message500 andcorresponding software message600 are authentic. A hash function such as SHA-1 or MD5 is run over the whole signatory group, whereafter the result is run through a signing algorithm such as RSA, ECC and DSA to produce the signature. Alternatively, a simple CRC algorithm could be used for the hash function, whereafter the result could be sent through an encryption algorithm such as triple-DES or DES to produce thesignature512. When compiling theauthorization message500, theheadend104 calculates thesignature512 over thewhole signatory group700 before inserting thesignature512 into theauthorization message500. The settop box108 calculates the signature of thesignatory group700 upon receipt of both the authorization andsoftware messages500,600. Once the signature is calculated, it is checked against the receivedsignature512 to authenticate portions of both the authorization andsoftware messages500,600. If the signatures do not match, the settop box108 discards thesoftware message600 because it presumably came from an improper source. Some embodiments could use multiple signatures to, among other reasons, support different settop boxes108 in thesystem100.
• The first and[0063]second checksums516,612 are calculated with either linear or non-linear algorithms. Thesechecksums516,612 verify the integrity of the data as it is transported to the settop box108 over thenetwork216. For example, the checksum could be a cyclic redundancy check (CRC) which performs a binary addition without carry for each byte in the message. Themessage spooler208 calculates thechecksum516 as themessage500 is being sent and appends thechecksum516 onto the end of themessage500. Conversely, the settop box108 calculates the checksum as themessage500 is received and checks the calculated checksum against thechecksum516 in the receivedmessage500. If the calculated and received checksums do not match, an error in transmission has occurred.Messages500,600 with errors are discarded whereafter theheadend104 may sendreplacement messages500,600. Some embodiments could use a digital signature rather than a checksum.
• The[0064]object header604 includes attributes for thesoftware message600. Included in theobject header604 are a header length, a software object length, the object identifier, the software version, and a domain identifier. The header length and software object length respectively indicate the lengths of theobject header604 and thesoftware object608. As described above, the object identifier provides a unique code that allows attributing theauthorization message500 to thesoftware message600. The software version indicates the version of the software object. Different cable providers are assigned domain identifiers such that all of the settop boxes108, which might receive asoftware object608, can screen for software objects608 associated with their domain.
• The[0065]software object608 includes content thesystem200 is designed to deliver to settop boxes108. Several types of information can be embedded in a software object, such as executable programs, firmware upgrades, run-time programs (e.g., Java® or ActiveX®), programming schedules, billing information, video, audio, or data. Thesoftware object608 can be used immediately after authentication and authorization or at a later time. Additionally, authorization can be programmed to expire after a certain amount of time.
• Referring specifically to FIG. 7, the[0066]signatory group700 is shown. Thisgroup700 is comprised of parts of both theauthorization message500 and thesoftware message600. All the data used to calculate the signature(s)512 is included in thesignatory group700. Because the signature(s)512 requires components from both theauthorization message500 and thesoftware message600, a failed signature check indicates one of theauthorization message500 and thesoftware message600 cannot be verified as originating from a trusted source. The trusted source being theheadend104 that generated thesignature512. If there aremultiple signatures512, the settop box108 chooses at least onesignature512 that it understands to authenticate thesignatory group700.
• Referring next to FIG. 8, an embodiment of a “rights”[0067]message800 is shown in block diagram form. Therights message800 conveys rights to use a functional unit. The functional unit could be an object or a resource. Typically, there is onerights message800 for each settop box108, which specifies any rights for all functional units. Requirements from theauthorization message500 that are associated with objects and resources are checked against the rights to determine if interaction with another object or resource is authorized. Therights message800 allows remotely adding new rights to a functional unit associated with the settop box108. Although not shown, therights message800 typically includes a digital signature to verify the integrity of themessage800 during transport. In some embodiments, a checksum could be used instead of a digital signature.
• The[0068]rights header804 includes attributes for therights message800. Included in therights header804 are a header length, a rights data structure length, aset top box108 identifier, and a domain identifier. The header length and the rights data structure length respectively indicate the lengths of therights header804 and therights data structure808. For authentication purposes, the settop box108 identifier provides a unique code that allows attributing therights message800 to a particularset top box108 in thesystem100.
• Rights are conveyed to all the functional units using the information in the[0069]rights data structure808. A given functional unit may have rights to use several other functional units. These rights are contained in therights data structure808. Each functional unit identifier lists tier rights that are used to attribute the rights to a particular functional unit. The functional unit may be already in the settop box108 or may be downloaded at some later time.
• Referring next to FIG. 9, interaction between functional units is shown in block diagram form. The functional units associated with the set[0070]top box108 include a settop box resource904, aprinter driver object908, ane-mail object912, and aprinter port resource914. During the normal interaction of these functional units, checkpoints are encountered that trigger authorization checks. The sole table correlates rights and requirements to each functional unit in FIG. 9. The functional unit identifier serves to correlate theobject messages600 with therights messages800.

  TABLE
  Functional
  Unit ID	FunctionalUnit	Requirements	Rights
  904	Set Top Box	NA	E-mail, Printer Driver, etc.
  912	E-mail	Yes	Printer Driver
  908	Printer Driver	Yes	Printer Port
  914	Printer Port	Yes	None

• The set[0071]top box resource904 is superordinate to theemail object912. When theemail object912 is loaded, a checkpoint in theobject912 checks for proper rights. The proper rights are defined by the requirements920-2 of theemail object912 itself. If the e-mail right916-1 meets the standards of the e-mail object requirements920-2, thee-mail object912 continues execution past the checkpoint. TheACP240 actually performs the authentication after the e-mail right916-1 and e-mail object requirements920-2 are respectively loaded by their associatedfunctional units904,912.
• After the user receives the set[0072]top box904, the user can add anoptional printer212. In this embodiment, the ability to print is an added feature that is not included in all settop boxes904. If theprinter212 is a purchase sanctioned by the content provider, printer driver rights916-2,916-4 and a printer port right916-3 are sent inrights messages800 to the settop box904 from theheadend104.
• Some embodiments could provide rights to a subset of the functional units capable of using the printer port[0073]920-3. For example, thee-mail object912 could be given the printer driver right916-4, but the settop box resource904 would not receive the printer driver right916-2. In this way, only the email object916-2 could use the printer port920-3 and the other objects could not.
• Hooking the[0074]printer212 to theprinter port914 can trigger display of a message on theTV216 that asks for a secret code included with theprinter212. After the user enters the secret code, a request for therights messages800 that enable theprinter212 is made to theheadend104. Once theheadend104 receives and verifies the secret code, an enabling set ofrights messages800 are sent encrypted in a key based upon the secret code. In this embodiment, theprinter driver object908 is factory loaded, but other embodiments could load thisobject908 when needed using anobject message600.
• While the[0075]e-mail object912 is running, the user may try to print an e-mail message. Several checkpoints authenticate theproper rights916 are present before printing. Thee-mail object912 calls theprinter driver908 with the information requiring printing. A checkpoint in theprinter driver908 stops processing until the authorization of thee-mail object912 is checked. A printer driver right916-4, downloaded when the printer was purchased, is loaded into theACP240 along with the printer driver requirements920-1 for authentication. Presuming authentication is successful, theprinter driver object908 formats the print information for theprinter212 and passes it to theprinter port resource914.
• The[0076]printer port resource914 is the hardware port that interfaces to a cable connected to theprinter212. Once information is sent to the printer port resource914 a checkpoint pauses the processes to check that theprinter driver object908 has proper authorization. The requirements920-3 and rights916-3 are loaded into theACP240 for authentication. Once the use by theprinter driver object908 is authenticated, the remainder of the print job is spooled to theprinter port resource914 for printing.
• In some embodiments, the[0077]rights916 of one functional unit can be inherited by another functional unit. The right916 could be conveyed toother objects608 that might use that functional unit. For example, the right916 to use theprinter port232 could initially be associated with thee-mail object912 alone, where this right916 is conveyed toe-mail object912 when the user purchased aprinter212. At a later time, theheadend104 could authorize inheritance of that right916 to all other functional units or subset of the functional units that might use theprinter port232. In this way, additional functional units could use the print feature.
• Referring next to FIG. 10, an embodiment of a process for loading an object in a third security level is depicted. This embodiment authenticates the network operator is the source of the object before launch. In a[0078]first step1004, thecontroller220 reads the authorization and objectmessages500,600 from a non-volatile portion of thememory228. Theobject message600 is loaded into theACP240 instep1008 and theauthorization message500 is loaded instep1012.
• Once both object and[0079]authorization messages600,500 are loaded, all the components of thesignatory group700 are available to theACP240. Instep1016, theACP240 calculates the signature over thesignatory group700. TheACP240 makes a determination instep1024 as to whether thesignature512 in theauthorization message500 matches the calculated signature. If there is a match, theobject608 is authorized and theobject608 is loaded intomemory228 by the OS and allowed to execute. Alternatively, theACP240 discards theobject608 and notifies the OS of an error if the signatures do not match. Asignature512 mismatch could result from corruption during storage, a pirate replacing theobject608 or a virus corrupting theobject608.
• With reference to FIG. 11, a flow diagram of an embodiment of a process for loading an object in a fourth security level is shown. This embodiment checks that the set[0080]top box108 is authorized to use the object prior to launching theobject608. Similar to level one security explained above, this embodiment uses encryption to achieve the authorization check. Either symmetric or asymmetric keys could be used for the encryption. In afirst step1104, theobject message600 is written in encrypted form to a non-volatile portion of thememory228. In some embodiments, theobject message600 is received from thenetwork208 in encrypted form such that an additional encryption step would be unnecessary before storage.
• When loading the[0081]object608 is desired, the authorization and objectmessages500,600 are retrieved from thenon-volatile memory228 instep1108. Theauthorization message500 includes a key necessary to decrypt theobject message600. The key and theobject message600 are loaded into the ACP instep1112. Theobject608 is decrypted instep1116. If the key used for decryption is not the one that is authorized for theobject608 the decryption process will be unsuccessful and the resulting product will be undecipherable. Alternatively, the plaintext object is returned to the OS for execution if the key is correct instep1120.
• In one embodiment, the[0082]object608 is loaded into volatile memory in encrypted form. Since only theobject608 from theobject message600 is stored in memory, theobject608 is encrypted by itself. The same key or a different key could be used to perform the encryption. When subsequent checkpoints are encountered, the authorization can be performed on theencrypted object608 in memory. For example, when theobject608 is read from memory for playback or viewing it is decrypted to once again verify authorization. User interaction, such as entry of a password, is not required during the authorization process.
• Referring next to FIG. 12, a flow diagram of another embodiment of a process for loading an object in the fourth security level is illustrated. In this embodiment, entitlements in the[0083]authorization message500 are checked in order to confirm theobject608 is authorized before it is loaded. Instep1204, theauthorization message500 is read from thememory228. Next, thecontroller220 loads theauthorization message500 into theACP240 instep1208.
• Once the[0084]ACP240 has theauthorization message500, the entitlement information therein is checked instep1212. A determination is made instep1216 as to whether theobject608 is authorized by checking the entitlement information. If theobject608 is authorized, it is loaded into memory by the OS and executed. Alternatively, the OS is notified of a failed authorization attempt and object608 is discarded instep1224 if there is no entitlement to use theobject608.
• Although not expressed above, the authorization of level four is typically performed at about the same time as the authentication of level three and before an[0085]object608 is loaded. Authorization is performed prior to authentication because authorization is a quicker process. After the performance of authentication and authorization, the status returned to the OS is NOT AUTHORIZED, AUTHORIZED BUT NOT AUTHENTICATED, or AUTHORIZED AND AUTHENTICATED.
• With reference to FIG. 13, a flow diagram of an embodiment of a process for checking continuously running objects in a fifth security level is depicted. The fifth security level and sixth security level (described below) relate to checkpoints triggered by time or usage. As can be appreciated, objects that are running should also be authenticated to be sure they haven't been replaced or modified. Additionally, verifying authorization periodically allows the expiration of an application that has been continuously running for a period of time. A predetermined period can be used or an unpredictably changing period can also be used.[0086]
• The process begins in[0087]step1304 where theobject608 is read from thememory228. Before loading theobject608 it has a first signature, but after loading theobject608 intomemory228, the signature of the loadedobject608 may change. As those skilled in the art appreciate, the addresses are translated from virtual addressing to physical addressing such that the signature can change. Accordingly, the signature is recalculated instep1308 to produce a second signature indicative of the loaded object. It is noted, theobject608 should be loaded and maintained inmemory228 in such a way that the second signature does not change. For example, the loaded object should not have self-modifying code such that the signature would change. Some embodiments, however, could allow modifications to the second signature as changes occur.
• The OS has checkpoints scheduled at regular intervals that trigger periodic authentication and authorization. In[0088]step1312, the process waits for the next scheduled checkpoint. Typically, these scheduled checkpoints occur at least weekly or monthly. As cable TV services are paid monthly, checking for unauthorized continuously running applications after the billing cycle is desirable, however, any interval could be used. Authentication and authorization is performed instep1316 by loading theauthorization message500, loaded object and second signature into theACP240. The second signature is used for authentication.
• A determination is made in[0089]step1320 as to whether the authentication and authorization performed instep1316 were both performed successfully. If successful, the process loops back to step1312 where the process waits for the next checkpoint. Alternatively, the object is removed frommemory228 and discarded when either the authorization or authentication checks fail. Preferably, theACP240 is the time source for determining the scheduled checkpoints. TheACP240 is less susceptible to attacks that set the clock back to avoid expiration of authorization. Additionally, theACP240 does not run application software that could change the time and requires secure commands to change the time. Secure commands could use encryption or signatures to guarantee authenticity of any time changes. To expire authorization, keys used for decryption could be expired or anew rights message800 could be sent that overwrites and removes the right to use an object.
• Although the preceding embodiment relies upon time periods to trigger checkpoints, other embodiments could trigger checkpoints in other ways. For example, usage could be monitored with a counter to trigger a checkpoint. After a predetermined number of loads or a predetermined cumulative running-time, a checkpoint could require re-verification of the object.[0090]
• Referring next to FIG. 14A, a flow diagram of an embodiment of a process for allowing a free preview of an object in security level six is illustrated. The sixth level of security allows using the software based upon some exemplar before a purchase is required. As is well known in the art, users desire to try software before possibly purchasing it. Accordingly, the sixth level of security allows using the software for a period of time before a purchase is requested.[0091]
• The process begins in[0092]step1404 where theobject608 is retrieved from a storage portion of thememory228. Instep1408, theobject608 is loaded into an execution portion of thememory228 where execution of theobject608 is initiated. A countdown timer is begun instep1412 that counts down to zero to mark the end of the trial period. It is to be understood a count-up timer could alternatively determine expiration of the trial period. The user samples theobject608 instep1416 until the trial period ends. Completion of the sample period is determined instep1420 by noting when the countdown timer expires or reaches its lower bound of zero. When the timer expires, so does a temporary authorization of the trial period.
• The user is given the option to purchase the[0093]object608 instep1424 while authorization of the application is suspended. Purchase will reinstate authorization. A purchase screen is formulated and presented to the user by the settop box108 to prompt purchase of theobject608. If no purchase is selected, theobject608 is removed frommemory228 and discarded instep1432. Alternatively, theobject608 remains inmemory228 and the entitlement information is updated to reflect the purchase and authorization instep1428 if the purchase is consented to.
• Other embodiments could use crippled demonstration software that can run forever, but is missing some features present in the purchased version. If the user likes the crippled version, the user is likely to purchase the full version to get the missing features. Purchase un-cripples the[0094]object608 and authorizes the missing features. It is noted that in some embodiments that the full version may be subject to expiration of the right to use the application in a manner similar to that depicted in FIG. 13.
• Referring next to FIG. 14B, a flow diagram of another embodiment of a process for allowing a free preview of an object in security level six is illustrated. In this embodiment, the trial period for the object is defined by a number of uses or some other measurement. For example, a software program could be loaded twice before requiring purchase.[0095]
• The process begins in[0096]step1436 where theobject608 is retrieved from the storage portion ofmemory228. Instep1440, theobject608 is loaded into the program execution portion ofmemory228 where execution is performed. A count-up usage counter is begun instep1444 that counts-up when the object is used. It is to be understood a count-down counter could alternatively determine when the usage limit is reached. The user samples theobject608 instep1448 and the sampling causes increment of the usage counter instep1452. Each usage count in this embodiment corresponds to a program load or some other action. Completion of the sample period is determined instep1456 by noting when the usage counter reaches its upper bound. When the limit is reached, the trial period authorization is expired.
• The user is given the option to purchase the[0097]object608 instep1460 while authorization of the application is suspended. Purchase will reinstate authorization. A purchase screen is formulated and presented to the user by the settop box108 to prompt purchase of theobject608. If no purchase is selected, theobject608 is removed frommemory228 and discarded instep1468. Alternatively, the object remains in memory and the entitlement information is updated to reflect the purchase and authorization instep1464 if the purchase is consented to.
• Although the preceding embodiment measures usage of the[0098]whole object608, other embodiments could monitor usage in more sophisticated ways. Individual functions of theobject608 could have metered access. For example, an e-mail program could be allowed to print twenty e-mail messages before requiring purchase of the print capability.
• With reference to FIG. 15A, a flow diagram showing an embodiment of a process for monitoring reports back to a[0099]headend104 in security level seven is shown. A monitoring computer in theheadend104 expects eachACP240 in thesystem100 to periodically send a security report back theheadend104 through thenetwork208. ThoseACPs240 that fail to report back within a predetermined period are presumed to have malfunctioningACPs240, which could indicate a hacked or otherwise malfunctioning settop box108. In this embodiment, the headend expects at least one security report each day. Only the process for monitoring a singleset top box108 is shown in FIG. 15A, but it is to be understood that the process is performed in parallel on a large number of settop boxes108 in thesystem100.
• In[0100]step1502, a reportback timer is set to an initial value of one day. After setting, the reportback timer starts counting down in time. For the settop box108 subjected to this process, theheadend104 monitors for any reportback from the settop box108 instep1506. Instep1510, a test is performed to determine if the security report has been received. If the report is received, processing continues to step1546 where the report is analyzed for any identified security problems. Where there are security problems, theset top box1518 may be disabled instep1518. Where there are no security problems, processing loops back tostep1502.
• If no report is received before[0101]step1510, processing continues to step1514 where a further test is performed to determine if the reportback timer has expired. If the timer has not expired, processing loops back tostep1506. The settop box108 corresponding to the expired timer is disabled instep1518, if the timer has expired. An expired timer would indicate theACP240 is no longer properly reporting security problems. To disable the settop box108, anew rights message800 could be sent that disables a key function of the set top box3 instep1518 such as the infrared port resource. Further, a message could be displayed on the settop box108 informing the user to contact customer support to re-enable the infrared port resource.
• Although this embodiment disables the whole set top box in response to an unfavorable security report, some embodiments could disable only the[0102]object608 that caused the security problem. If the operating system (OS) in the settop box108 becomes corrupted in memory, for example, subsequent checkpoints may not be properly responded to. TheACP240 would report this error after observing checkpoints going unperformed. A command to the settop box108 could be sent by theheadend104 to cause reload of the OS in the hope of clearing out the error. If further reports are received, the settop box108 could be disabled.
• Referring next to FIG. 15B, a flow diagram showing an embodiment of a process for reporting security checks by a set[0103]top box108 in security level seven is shown. TheACP240 monitors for proper operation ofobjects608 and the OS when checkpoints are, or should be, encountered. For example, some embodiments execute a checkpoint whenever anobject608 is loaded, launched or accessed. TheACP240 would make sure that authentication and/or authorization is performed and that any unfavorable results are acted upon. Failure to handle checkpoints properly is reported to theheadend104 in a security report.
• In[0104]step1522, a reportback timer is set. The reportback timer sets the period at which the settop box108 will normally send security reports back to theheadend104. In this embodiment, theACP240 sends reports every hour. These reports are in addition to authentication and authorization error reports from the OS andcontroller220. TheACP240 independently determines when a checkpoint should be encountered by the OS and objects608 instep1526. Insteps1530 and1534, theACP240 determines if authentication and/or authorization were performed in response to the checkpoint. If either test fails, theACP240 further determines if the error is reported back to theheadend104 by thecontroller220. TheACP240 is involved in the authentication and/or authorization process and can determine when these processes are performed. The monitoring of error reports can be done by theACP240 auditing traffic on thesystem bus230 to see if thenetwork port208 is properly sent the error report.
• If a checkpoint is ignored or otherwise not acted upon, a security report is immediately sent to the[0105]headend104 instep1542. The security report includes all errors that occurred since the last reportback timer period began. If the checkpoint is properly performed, processing continues to step1538 where expiration of the one-hour report back period is tested. A security report is sent by theACP240 when the timer expires instep1542, otherwise, processing loops fromstep1538 back to step1526 for further monitoring. In this embodiment, theACP240 performs simple checks on the rest of the settop box108 to independently check for security problems and also reports those problems back to theheadend104.
• With reference to FIG. 15C, another embodiment of a process for monitoring security checks in security level seven is depicted in flow diagram form. In this embodiment the[0106]ACP240 shadows the OS to double-check that checkpoints are encountered regularly. The process begins instep1504 where the time of the last OS checkpoint is recorded. Since theACP240 is involved in the authentication and authorization process in this embodiment, theACP240 can track execution of checkpoints. Instep1508, the countdown timer is started. We note once again that this counter could also count-up rather than-down.
• In[0107]step1512, a determination is made as to whether a checkpoint was observed by theACP240. If a checkpoint was observed, processing loops back to step1504 where the countdown timer is reset so as to start again from the beginning. Alternatively, a check of the timer is performed instep1516 if no checkpoint is observed. If the counter has not expired, processing loops back to step1512 to test once again for the observation of a checkpoint. When the timer does expire without reaching a checkpoint, processing continues to step1520 where theACP240 reports an error back to theheadend104.
• Although the above embodiment discusses testing for checkpoints on a[0108]single object608, it is to be understood that testing for checkpoints may occur for eachobject608 in the settop box108 in the manner described above such that many of the depicted processes are performed in parallel. In some embodiments, custom criteria may be designed for eachobject608 in order to detect errors in the execution unique to thatobject608. Additionally, we note a trusted or secure operating system normally may not need anACP240 to check for aberrant behavior in such a rigorous manner. To thwart hackers, pirates, viruses, and memory errors, checking for normal functioning of the operating system (i.e., check for regular checkpoints) adds an extra layer of security.
• With reference to FIG. 16A, a flow diagram of an embodiment of a process for producing partially-encrypted objects in an eighth level of security is shown. A portion of the object is encrypted to prevent unauthorized launches of the object until the[0109]object608 is purchased. For example, a crippled version of theobject608 could be made available until purchase causes decryption of a token in order to reformulate an un-crippled version of theobject608. Decrypting the token effectively authorizes use of the un-crippled version such that thewhole object608 is available in plaintext form. In this embodiment, the portion of theobject608 used for the token is less than half the size of thewhole object608.
• Processing begins in[0110]step1602 where the portion of theobject608 to encrypt as a token is chosen. The portion is chosen such that its absence from theobject608 does not allow execution of theobject608. The portion removed is encrypted as a token instep1606. Either symmetric or asymmetric encryption may be performed, however, this embodiment uses symmetric encryption. Instep1610, the crippled or secure object is sent to the settop box108. Included in the secure object are the token and the remainder of theobject608 in plaintext form. Instep1614, the symmetric key is sent to the settop box108 over a secure channel.
• If the user purchases the[0111]object608, the token is decrypted and reinserted into theobject608 such that the reformulated object is executable. A message is sent to theheadend104 from the settop box108 instep1618 indicating a purchase was made. Instep1622, the user's account is properly debited for the purchase of theobject608. An updatedrights message800 is sent that authorizes use of the object instep1626. Although this embodiment gets final authorization from theheadend104, some embodiments could avoid this authorization to begin use of the object immediately. For example, authorization from theheadend104 may be impractical in store-and-forward systems.
• Referring next to FIG. 16B, a flow diagram of an embodiment of a process for using tokens to achieve the eighth level of security is shown. This embodiment uses a ciphertext token to control authorization of an[0112]object608. The ciphertext token is an encrypted portion of theobject608 needed for normal operation of theobject608 or some sub-function thereof. Decryption of the ciphertext token produces a plaintext token that is inserted into theobject608 such that the object is reformulated in plaintext form.
• In[0113]step1604, the process begins by receiving the ciphertext token and the plaintext remainder of theobject608 from the headend. Although this embodiment relies upon theheadend104 to create the ciphertext token, some embodiments could perform the encrypting of the token in the settop box108 afterobject608 is received. The plaintext remainder and ciphertext token are stored instorage memory228 instep1608. The key needed to decrypt the ciphertext token is received and stored in theACP240 instep1612.
• The process waits in[0114]step1616 until the user purchases theobject608. Instep1618, the ciphertext token is removed from theobject608 and sent to theACP240 for decryption. The resulting plaintext token is returned to the OS and integrated into theobject608 to make theobject608 functional insteps1620 and1624. Instep1628, the purchase is reported to theheadend104. Before execution of theobject608, further authorization from theheadend104 in the form of arights message800 may be required. By encrypting only a portion of theobject608 rather than thewhole object608, the decryption process is accelerated.
• The above discussion relates to running applications or objects[0115]608 on an OS. These concepts are equally applicable to Java™ applications running on a Java™ virtual machine (JVM) which runs on top of the OS. To aid in this abstraction, the concept of superordination and subordination are explained in relation to FIG. 17. Superordination and subordination define which object608 has the responsibility to impose a checkpoint upon another object. Checkpoints are imposed onobjects608 during the normal interaction that occurs withother objects608 and resources.
• With reference to FIG. 16C, a flow diagram of another embodiment of a process for using partial download to achieve the eighth level of security is shown. This embodiment divides the object into a plaintext portion and a plaintext remainder. The[0116]headend104 distributes the plaintext remainder, but waits for a purchase before distributing the plaintext portion. Without the plaintext portion, theobject608 is crippled such that it cannot be executed. In this embodiment, the plaintext portion is less than one-tenth the size of the plaintext remainder.
• In[0117]step1650, the plaintext remainder of theobject608 is received by the settop box108 and stored inmemory228 instep1654. Nothing is done to the plaintext remainder unless the user purchases use of it instep1658. The purchase is reported back to theheadend104 by way of thenetwork208. Once any verification is performed upon the purchase request, theheadend104 sends the missing plaintext portion that is received instep1666. A secure channel is used to send the plaintext portion to the settop box108 that purchased theobject608.
• In[0118]step1670, the plaintext portion and remainder are joined to reformulate theobject608 at the settop box108. This embodiment further requires anew rights message800 from theheadend104 to enable use of the object. Thenew rights message800 would replace theold rights message800 and provide rights to use theobject608.
• With reference to FIG. 17, some of the functional units of a set[0119]top box108 are shown. Functional units toward the bottom of FIG. 17 are superordinate to the functional units near the top of FIG. 17. That is to say, functional units toward the top of FIG. 17 are subordinate to those lower in the figure. Superordinate functional units are responsible for imposing checkpoints on subordinate functional units. For example, thehardware1704 imposes checkpoints upon theBIOS1708,OS1712 and so on up the subordination hierarchy. TheBIOS1708 imposes checkpoints on theOS1712, but not upon thehardware1704. Functional units in the same ordination stratum can impose a checkpoint on another functional unit in that stratum when they interact. For example, anapplication1716 can require execution of a checkpoint on adriver1718.
• Superordinate functional units are designed to initiate execution of the checkpoints in conjunction with the[0120]ACP240 and subordinate objects are designed to have checkpoints imposed upon them. For example, theBIOS1708 requires execution of a checkpoint upon theOS1712 during the boot process, during execution and/or periodically while running. Adriver object1718 is subject to checkpoints when installed or exercised during normal operation. Data file objects1722 are subject to checkpoints whenever the data in the file is accessed. AnHTML object1728 is reviewed as part of a checkpoint whenever theHTML object1728 is interpreted by abrowser application1716.
• In light of the above description, a number of advantages of the present invention are readily apparent. Authorization is further enhanced by obscuring part of the object. Some embodiments do not send the missing portion to the set top box until a purchase request is made such that authorization involves the headend, which is less susceptible to corruption.[0121]
• While the principles of the invention have been described above in connection with specific apparatuses and methods, it is to be clearly understood that this description is made only by way of example and not as limitation on the scope of the invention.[0122]

Claims (19)

What is claimed is:

1. A method for securing a plaintext object within a content receiver, the method comprising steps of:

receiving a secure portion of a secure object;

receiving a plaintext remainder of the secure object;

determining which portion of the secure object is the secure portion;

decrypting the secure portion to provide a plaintext portion;

forming the plaintext object that comprises the plaintext portion and the plaintext remainder; and

storing the plaintext object.

2. The method for securing the plaintext object within the content receiver as recited inclaim 1, further comprising steps of:

selecting a secure portion of the plaintext object to encrypt;

encrypting the secure portion;

sending the secure portion and a plaintext remainder to a content receiver; and

providing a key that is used in decryption of the secure portion.

3. The method for securing the plaintext object within the content receiver as recited inclaim 1, further comprising a step of reporting purchase of the plaintext object a point away from the content receiver.

4. The method for securing the plaintext object within the content receiver as recited inclaim 3, wherein the second listed receiving step is performed before the reporting step.

5. The method for securing the plaintext object within the content receiver as recited inclaim 1, wherein the decrypting step comprises a step of decrypting the secure portion with an access control processor.

6. The method for securing the plaintext object within the content receiver as recited inclaim 1, wherein the secure portion is less than one-half the size of the secure object.

7. A method for securing a plaintext object within a conditional access system, the method comprising steps of:

selecting a secure portion of the plaintext object to encrypt;

encrypting the secure portion;

sending the secure portion of the plaintext object to a content receiver;

sending a plaintext remainder of the plaintext object to the content receiver; and

providing a key to the content receiver wherein the key is used in decryption of the secure portion.

8. The method for securing the plaintext object within the conditional access system as recited inclaim 7, further comprising steps of:

receiving the secure portion of a secure object;

receiving the plaintext remainder of the secure object;

determining which portion of the secure object is the secure portion;

decrypting the secure portion to provide a plaintext portion;

forming the plaintext object that comprises the plaintext portion and the plaintext remainder; and

storing the plaintext object.

9. The method for securing the plaintext object within the conditional access system as recited inclaim 7, further comprising a step of reporting purchase of the plaintext object a point away from the content receiver.

10. The method for securing the plaintext object within the conditional access system as recited inclaim 9, wherein the reporting step is performed before the second listed sending step.

11. The method for securing the plaintext object within the conditional access system as recited inclaim 7, further comprising a step of determining the secure portion wherein removal of the secure portion from the plaintext object renders the plaintext object inoperable.

12. The method for securing the plaintext object within the conditional access system as recited inclaim 7, further comprising a step of changing authorization of the content receiver from a point remote to the content receiver.

13. The method for securing the plaintext object within the conditional access system as recited inclaim 7, further comprising a step of receiving purchase information from the content receiver at a location remote to the content receiver.

14. The method for securing the plaintext object within the conditional access system as recited inclaim 7, wherein the key is a symmetric key.

15. A method for securing an object within a content receiver, the method comprising steps of:

receiving a first portion of the object;

recognizing a purchase request from a user of the content receiver for the object;

reporting the purchase request to a point away from the content receiver;

receiving a second portion of the object after the reporting step; and

storing the object in the content receiver.

16. The method for securing the object within the content receiver as recited inclaim 15, wherein the second portion is received in encrypted form.

17. The method for securing the object within the content receiver as recited inclaim 15, wherein the first portion is greater than nine hundred percent larger than the second portion.

18. The method for securing the object within the content receiver as recited inclaim 15, further comprising the step of reformulating the object from the first and second portions.

19. The method for securing the object within the content receiver as recited inclaim 15, wherein the second listed receiving step comprises a step of receiving the second portion by way of a secured distribution channel.

Images