MXPA01008592A - Authorization and access control of software object residing in set-top terminals - Google Patents

Authorization and access control of software object residing in set-top terminals

Info

Publication number
MXPA01008592A
MXPA01008592A MXPA/A/2001/008592A MXPA01008592A MXPA01008592A MX PA01008592 A MXPA01008592 A MX PA01008592A MX PA01008592 A MXPA01008592 A MX PA01008592A MX PA01008592 A MXPA01008592 A MX PA01008592A
Authority
MX
Mexico
Prior art keywords
software
software object
terminal
decoder
decoder terminal
Prior art date
Application number
MXPA/A/2001/008592A
Other languages
Spanish (es)
Inventor
Reem Safadi
Lawrence Vince
Original Assignee
General Instrument Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by General Instrument Corporation filed Critical General Instrument Corporation
Publication of MXPA01008592A publication Critical patent/MXPA01008592A/en

Links

Abstract

A method for providing authentication, authorization and access control of software object residing in digital set-top terminals creates a fingerprint ("signature") for each software object, associates each fingerprint with a service tier, encodes each association and creates an association table containing the information and downloads the association table to the digital set-top terminal. In addition, the method utilizes an entitlement management message, sent to each set-top terminal, indicating what software objects the set-top terminal may utilize, and provides a system routine at the digital set-top terminal that is invoked whenever software object is about to be utilized. The entitlement management message contains the access rights given to a particular set-top terminal, which must match the software object's access requirements for the software object to be utilized. The entitlement management message may also contain set-top terminal resource control access rights that a given software object may utilize. When the software object requires the utilization of a set-top resource, a second conditional access routine may be invoked to determine the authorization rights for using the resource. Measures to protect such means are also described. As such the method provides multiple system cable operators (MSO's) with additional capabilities to maintain secure control of features and applications running on their networks and within the associated set-top terminals.

Description

CONTROL OF ACCESS AND AUTHORIZATION OF THE OBJECT OF THE SOFTWARE THAT RESIDES IN THE TERMINALS OF THE DECODER Field of the Invention The present invention generally relates to a method for providing an authorization, verification and access control of "executable codes" or "software object", which includes, but is not limited to, an application code, systems operating systems and associated components (for example, dynamic link libraries - DLL's), BIOS, Java Virtual Machine (JVM), Java applications and applets, etc., that reside in the terminals of the decoder.
Antecedents of the Invention Because the digital terminals of the decoder (for example, the General Instrument DCT5000 +), incorporate the ability to download different operating systems, JVM DLLs (including Windows CE), multiple cable system operators (MSOs) need a mechanism that allows them to maintain control of the features and applications that operate within these decoder terminals. More specifically, MSOs need the capacity for access control services and the associated use of the software objects in the decoder terminals. A known attempt to address the authenticity of code objects for the PC environment is, Microsoft's "Authenticode" capability. This product makes it possible for software vendors to acquire a digital signature for the published executable code. The Authenticode, provides a digital signature only with a signatory; the code is signed with the private key of Microsoft (which is not published) and is verified with the public key of Microsoft, which is incorporated within the verification code Authenticode in the operating system. However, although the Authenticode provides the digital signature protection for the executable code, it does not provide any means to determine the access requirements for the executable code for access control purposes (and income generating purposes) and is applicable only to the code ejcutable. A second attempt to address the control of Java applets is "Java Security", which aims to prevent applets from inspecting or changing files on a client system, or using network connections to circumvent protections of files or the data privacy measures. However, as in the case of Authenticode, Java Security does not offer object verification of any software, unless it is based on Java, nor does it offer the association with access requirements for access control and revenue generation purposes. . Although each of the products described above, try to address the object protection and control of the software in a PC environment, against the use not used by a particular set-top terminal, they do not fully address the problems associated with the authorization control, verification and access, and therefore, do not provide an optimal solution that meets the requirements of the MSOs.
Summary of the Invention As the decoder terminals assume a computing environment for entertainment purposes using downloaded software objects, such as operating systems, libraries, Java Virtual Machines, applications, applets, etc., it has become extremely critical to protect and control the object of the software to protect it against unauthorized use by a specific decoder terminal. According to the proposed concept, not only the identity of each object of the software requires verification, but also its use has to be subject to the control of the MSO by means of the authorization permits together with the control of which resource of decoder terminals can use an object of the given software. These measures complement those of the validation and verification of the object and ensure that software objects that have not been verified are not used. To the extent that these measures are used, the decoder terminal is no longer subject to the problems associated with the objects that have failed to follow the security design rules, or even worse, those can be contaminated with a virus, which means a danger to the MSO network and the terminals of the associated decoders. In a particular embodiment of the present invention, a method for providing authorization and access control of the software object, which resides in the digital terminals of the decoder, creates a fingerprint (signature) for each software object, associates each of fingerprints with a service insurer, encodes each association and creates an association table that contains the information generated by the encoding step (note, this table may consist of one or more association entries). In addition, the method sends the association table to the digital terminal of the decoder and also transmits a message indicating which objects of the software the terminal of the decoder can use, for the digital terminal of the decoder. Finally, the proposed method provides a system routine in the digital terminal of the decoder, which is invoked before starting the download of the object, once the object of the software has been downloaded, or optionally, provided that the object of the software is about to be used (or "invoked" if it is an executable code). The system routine, uses the association table to validate the authenticity of the object (verifies it) and determine if the object of the software to be used is associated with a corresponding service insurer, for which the decoder has been authorized, if the download of the object of the download (or use) of the software object is not allowed. However, if the object of the software that is about to be downloaded (or used), is associated with a service insurer for which the decoder has been authorized and the download (or use) of the object is allowed. According to another aspect of the present invention, the object of the software has been verified and validated, before the aforementioned steps. In accordance with yet another aspect of the present invention, the transmitted message further includes which encoder terminal resource is authorized to use the object of the software or decoder as a whole. Yet another additional advantage provided by another feature of the present invention is that if the object of the software that is about to be invoked contains the correct fingerprint and the authorization rights coincide with the authorization requirements associated with the software object, the method further determines if the use of the resource of the decoder terminal has been authorized. In one embodiment, if a determination has been made that the use of the terminal resource of a decoder has been requested, the method also provides a second system routine in the digital terminal of the decoder, and the second routine of the system uses the transmitted message to determine if the software object can use the resource of the requested decoder terminal. In the event that the resource is authorized, as in the authoritative Impulse resource (associating it with an Impulse insurer in the message), the user is allowed to request an Impulse authorization (immediate) of this resource. This prevents the subscriber (user) from having to call the MSO customer service center to request such authorization. A further advantageous feature of the present invention is that if the software object that is about to be used does not contain the correct fingerprint, the software object is not exempted.
BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a simplified block diagram illustrating the logical trajectories of a cable system important for the description of the present invention. Figure 2 is a simplified flow chart illustrating the steps taken by a multiple cable system operator (MSO) to provide authorization and access control of the software object at the terminals of the decoder. Figure 3 is a simplified flow chart, illustrating the steps performed by a Conditional Access (CA) routine, a decoder terminal when invoking the software object. Figure 4 is a simplified flow chart, illustrating the additional steps performed by a second control routine of Conditional Access (CA) in another embodiment of the present invention.
Detailed Description of the Invention Multiple operators of cable systems need to extend their access control capabilities, for example, to control the ability to access and use software objects in decoder terminals with the capacity to download those objects and then use them if its download and use is authorized, and the objects pass the verification checks. Access control of a software object according to one aspect of the present invention, consists of three parts. The first defines the access requirements for a particular service (and associated objects) and the second defines the authorization rights for a particular decoder terminal to access these services (and the associated objects). The third part provides the additional identification information to enable the decoder terminal to verify the objects before use. The access requirements can be considered as the lock and the authorization rights can be considered as the key. When the authorization rights match the access rights (and no parental control is required), the decoder terminal is allowed to access the service (and associated objects). There are two types of messages that facilitate the function of access control. First, the Rights Control Message (ECM), provides the Rights Control Structure (ECS) (which will be explained in more detail below), which contains the Rights Control Record (ECR) (which will also be explained). in more detail below), for the associated objects and lists the required rights information so that the programs can be viewed or the objects used. The second message, the Rights Management Message (EMM), provides the rights purchased by or granted to the consumer. The functions of each of these messages will be described in more detail later. The following description provides an overview of the way in which the software objects are authorized to operate, (after verification). All software objects that are not authorized (and verified) in this way, can not be used by the decoder terminal. In the event that all preventive measures attempted to keep the software objects unauthorized within the terminal of the decoder fail, this method helps to detect such applications and to prevent their use or execution. In the digital decoder terminal, the use of all software objects, (including the applications associated with a given service) must be authorized by the access control system. It is specified that the software object consists of a downloadable code or data that can be used in the decoder terminal, either by the subscriber, or by the MSOs. First, as illustrated in the block diagram of Figure 1, an Object Verification Signature Apparatus 300 (OASD) uses, either, the National Access Controller 310 (NAC) (in the national control scenario) or a Local Access Controller (LAC) (in the local control scenario), to interact with a number of decoder terminals 350a, 350b, etc. The details of the interactions of each of these apparatuses are described in detail below in relation to the detailed description of the invention. Referring to the flowchart of Figure 2, in step 10, a "fingerprint", for example, a digital signature, is created for each software object (for example, applications of OS, DLL, JVM, Java applications). and applets, etc.). The fingerprint (signature) of the software object, serves as a record of Unique Rights Control (ECR). For example, each software object that wants to place the MSO in this category, for example, under control, is associated with a "fingerprint". Observe that the fingerprint, could simply be a seed for a key that could be encrypted by known means or, it could be a value that is derived from an initial value through the processing of it, as an image or otherwise (for example, the fingerprint can include the size of the object, the revision of sum, etc.). In particular, the fingerprint (a digital signature) may be generated by an object verification apparatus HW / signature / software (OASD). This is done after the software object has been verified and validated (either through inspection, testing, etc. - whose details are beyond the scope of this request). The purpose of software verification and validation is to ensure that the design and implementation of the object follows a set of previously specified rules and requirements established for security purposes. This can be done under contract with the MSO (whose details are also outside the scope of the present application). The signature may be based on a unique identifier of the object (which may or may not be specific to the MSO) and a cryptographic CRC of the object, and serves as a certification form that is unique to the software object itself (several may be used). conventional signature techniques, whose details however, are beyond the scope of this application). If several software objects are associated with a service, each one can be associated with a signature, and then, a general signature can be provided for the whole set, whenever the verification of a higher level association is desired. Continuing to step 20 of Figure 2, the fingerprint of each software object is then associated with a service insurer. Both cable access control systems and satellite access control systems use the concept of "assurance". For audiovisual services, an insurer is a logical grouping of programs or services (being the degenerate case, a single program or service). The grouping is created to facilitate the control of the access of the users (subscribers) to that group of services based on the profile of subscribers of the MSO (for example, whose services are subscribed by a determined consumer). The access rights of the user would demand a lot of memory in the terminal of the decoder, if the access rights were stored as separate signals for each and every one of the available programs or objects. Insurers are usually represented as simple binary digits (bits) that can be defined and dynamically re-defined. As each insurer (or group) is represented as a single bit, and the insurers are defined as important for the service they offer at a given point in time, they offer the most compact representation possible for the user's access rights (the compacted is very important, since access rights must be kept in a secure memory which is limited, and must be transmitted frequently, and as such, bandwidth requirements are minimized). One or more objects may be associated with a particular service / application and assigned to the corresponding insurers. Additionally, although said authorization rights may be stored in a server at the other end of the network (as opposed to that of the decoder terminal), where the decoder terminal may request its rights by communicating with the server in real time, it is generally advantageous to distribute this information within the terminals of the decoder for reasons of safety, robustness, operation, as well as, minimization of the single point of failure effects. Once the event (or "program") ends, and once the object is no longer offered as part of a particular service, the definition of the insurer will be updated to reflect this change. The authorization insurers for which the subscribers have been used are transported in a Rights Registration Management Message (EMM) (which will be described in greater detail below, in the description of Figure 1, step 50). In a preferred embodiment of the present invention, there are two types of insurers, the first one, a subscription insurer, which is associated with a service (and the corresponding objects) that continue for the duration of time and which is purchased later of real use. The second, an Impulse Pay Per Use Insurer (IPPU, analogous to the Pay Per View Boost for video programming), which allows a Buying impulse of an object or set of objects associated with a given service / application and can have a duration of time associated with it. Those skilled in the art will appreciate that other uses, combinations or conditions may be based on these two types of insurers. Referring again to step 20 of Figure 2, more specifically, the fingerprint to service the insurer association may be assigned by the access controller of the MSOs (Access Controller (AC) for the National Access Controller). or for the Digital Access Controller (DAC) for local control) by adding a CA (Conditional Access) to the functionality of the subservice signature specific to the objects associated with the network of the MSOs. This function can be facilitated by the OASD, when it is acting as a subservice device for the AC or the DAC of the MSOs. As mentioned above, the OASD functionality can be incorporated into an independent device (software and hardware) which, in turn, would communicate with the AC or DAC to obtain the access requirement assignments (corresponding insurers for said object) .
The additional specific signature of MSO, takes the signature of a previously signed object (for example, fingerprint or "digital signature", generated by the OASD), and adds it to a unique object identifier (if an identifier is required). specific object of the MSO). Also, add any or more of the rights bits of the insurer, which define the access requirements associated with the corresponding software object, and a wrapper signature for the entire structure, which we refer to below as the Structure of Control of Rights (ECS). This unique and secret coding of the ECSs is shown in step 30. The ECSs may contain the access requirements for the object and the associated resources, or they may be divided into two ECSs, one for the access requirements for the object and another for resources. The latter method is generally a more appropriate method if the authorization of the resource is independent of a given object and is being performed on a broad base of decoders. However, any method can be used (for example, a combined ECS or two separate ECSs) and has no impact on the way in which the authorization steps are performed. The cost and the period of free use, together with the global restrictions of the resource of the decoder terminal, for example, can be assigned by this apparatus as they are specified by the AC or the DAC (which, at the same time, can be specified through the Billing System interface). These parameters are also transferred as part of the ECS within the ECM. The functionality of the OASD and MSO signatures, and the creation of the ECSs (steps 10 to 30), can be combined in a single device, which gives subservice to the AC or DAC, as it is in the case of the preferred modality, since which is the simplest case. In any case, the division of the physical product must not alter the functional steps that must be carried out (and you can optimize these steps). Continuing with step 40, of figure 2, in the MSO, the collection of unique ECSs forms an association table, which is made available to a national or local download function (Downloader) associated with the AC or the DAC, respectively, and it is downloaded to the digital decoder terminal (either in its entirety, or any entry at a time in an appropriate message, at the time of download). Whenever the downloader downloads protected software objects, it provides the digital terminal of the decoder with the "secret of the software object for association of the service insurer" (ECS) secret, which is preferably encrypted by known means before of the transmission. The downloader downloads the software object in a carousel mode, while the ECS in the associated ECM can be sent independently. Those skilled in the art will appreciate that this independence provides an additional security measure. Applicants note that, in an alternative embodiment of the present invention, if the authorization is not required, then the ECS can effectively consist only of the ECR (for example, step 20 of Figure 2 is not performed). The ECS in this mode, is carried on the slopes in the downloaded object. This decoder terminal checks that the ECS performs the verification check. The decoder download function downloads the first bytes N of the object (as indicated by the header information that accompanies the downloaded object) and ignores the final bytes that comprise the ECS. However, the preferred embodiment described above is preferred to this mode for two reasons: first, coupling the ECS to the object, eliminating any desirable security measure, and second, this mode introduces inconsistent processing between an ECS, which contains only one ECR and which contains the association of the ECR and the service insurer. Nevertheless, the preferred mode does not restrict the way in which the ECS can be transported, nor does it restrict the ECS to the type of message that specifies it (EMM or any other control message). Returning again to the description of step 40, of figure 2, the Downloader can be part of the AC or the DAC, since it can be seen as a task of the software, or alternatively, it can be separated from the DAC, for example, a task of the software, which operates on its own HW platform. The MSO, which uses the AC or the DAC (both are HW and SW devices) by means of the adjustment of parameters of the billing system and based on the profile of the client, then controls the access to the terminal of the decoder to a specific service and associated object or sets of objects, using the Rights Management Messages mentioned above (EMM's) specific to that decoder terminal. These messages also state whether the decoder terminal is allowed to use that software object and can also specify which decoder terminal resources are allowed to use that object (for example, communication ports, printer port, keyboard, etc.) ( when subscriber level control is desired). In addition, the AC or the DAC may selectively assign a Impulse authorization insurer (and transport the adjustment through the same message) to facilitate the immediate authorization of the requested resource, when the subscriber explicitly requests that the resource be authorized. In the case where the resource is authorized, as in the Impulse-authorisable resource, (associating it with an Impulse insurer in the message), the user can request a Impulse authorization of this resource (for example, immediate), avoiding in this way the subscriber (user) needs to call the MSOs for such authorization. Finally, in step 50, the AC or the DAC, send the EMMs to each and every one of the decoder terminals, to make it possible to download and use the object (more specifically, when the control of the resource is desired for a single object in all the global decoders, the list of the permission for the control of the resource, can reside in the ECS; otherwise, the permissions (access rights) are transported to each decoder individually in an EMM). The Access Controller (or DAC) then sends the concession to the decoder terminal that is authorized to receive this service and the associated objects (again, these authorizations are assigned in the EMMs described above). A system routine is created and provided in the decoder terminal and is invoked provided that the decoder terminal is going to review the authorization rights and the authenticity of the software objects associated with the requested service. This routine system can be part of a core code (BIOS) in the terminal of the decoder. It can also be provided within the operating system (OS) or middleware. Whenever the operating system or JVM download is invoked, for example, the resident routine is invoked to check the authorization of the rights before downloading it, and in this way, verify these objects after the download. A second authorization stage can also be present (for some objects) to check if the use / launch of these objects is allowed. Once the operating system is loaded, any subsequent utilization of the object comprising the operating system or the JVM invokes the equivalent authorization and authentication routine in the OS. More specifically, the decoder terminal checks and authorizes a downloaded object using the EMMs or ECMs associated with a particular decoder terminal and the object respectively. The decoder can review the authorization rights against the authorization requirements of the software object before downloading the object, during the download of the object, or whenever the object is to be used. Subsequent authorization revisions are optional. Figure 3 is a flow chart illustrating the steps performed in the decoder terminal when invoking the software object. In figure 3, step 100 is the download request. Accordingly, in step 110, the BIOS, operating system and / or Java Virtual Machine (JVM), when they require the download or use of a software object, call the decoder CA routine for an authorization check and revision. The use or release of the object is allowed only if the revision passes. The CA review is facilitated by the insurance processor. In addition, the time-of-life feature can be implemented, where the insurance processor records the useful life of the object and reviews its expiration, starting, for example, with the first use (for example, the first time the insurance processor was engaged in the verification and authorization of the object). When it has expired, it may interrupt the operating system or the JVM to disable / delete the object (s). If any of the revisions fails, the decoder terminal may record the results, to report back to the access controller. Again, this feature is a combination of software and hardware functions. More specifically, going back to figure 3, in step 120 a determination is made as to whether or not it may be necessary to review the authorization rights. If not, as illustrated in Figure 3, in step 130, the software object can be downloaded to the decoder terminal before any authorization. However, if the conditional access (CA) routine is required in step 200, before downloading the object, it can determine whether the decoder terminal is authorized to download the object. This step is optional and may depend on the nature of the software object (for example, some objects are necessary and may not require prior authorization). If the step is performed, and if a determination is made that the decoder terminal is authorized to download the object, the process continues to step 210. However, if a determination is made in step 200, that the decoder terminal is not authorized to download the object, the process continues to step 150, where the object is not used. In step 210, the software object is downloaded to the decoder terminal and the process proceeds to step 150 for verification, which will be described in more detail below. Alternatively, again, if a determination was made in step 120 that authorization rights need not be verified, the software object is downloaded (step 130) and as illustrated in step 140, the conditional access routine ( CA), determines if the decoder terminal is authorized to use / launch the software object. Based on this determination, the software object may or may not be used. None of the unauthorized software objects will have a corresponding insurer association. The "fingerprint" association of the software object to the "encrypted" insured value (ECS) of the software object (or "request" in this example), is only known to the MSO and by definition is unique to each software object and is protected.Therefore, if a determination is made in step 140 that the decoder terminal has not been authorized to use / launch the software object, the process proceeds to step 140, where the software object is not If the insurer corresponding to the object of the software has been authorized, the process continues to step 150. Continuing to step 150, the CA routine, again with the help of the insurance processor, checks to see if the object of software has a corresponding fingerprint association, depending on the result, the software object may or may not be used, for example, none of the unauthorized software objects will have a fingerprint. (since an object of the unauthorized software can not "guess" the corresponding ECR value). In that case, the process continues to step 160, where the software object is not used. The protected fingerprint of the software object is known only by the MSO and, by definition, is unique to each software object. If the software object has a corresponding fingerprint association, however, the process continues to step 170, where the decoder terminal authorizes and verifies the downloaded object. Those skilled in the art will appreciate that each of the authorization steps illustrated in steps 140 and 200 of Figure 3 are optional and do not necessarily have to be performed. In addition, although the authorization review performed in step 200 proceeds to step 210 and then to the verification of step 150, subsequent additional revisions could be made to the CA routine and are within the scope of the invention. Further, in a second embodiment of the present invention, if the software object requires the use of a particular decoder terminal resource, a similar revision process may occur to determine whether the software object is allowed to use the required resources . These permissions (authorization rights) may be associated with a specific object for all the decoder terminals or may be associated with a specific object of a specific decoder terminal. The authorization rights to use the resources of the decoder terminal are transported in a similar way, through the EMMs. As noted above, authorization rights can also be designated as Impulse insurers to indicate that the subscriber can request immediate authorization of the Authorized Impulse resource. The decoder, in turn, reviews the request in a similar manner, and if it is adjusted to the Impulse insurer, it registers it as if the authorization had existed (for possible subsequent billing purposes).
Each of these options are illustrated in Figure 4, wherein in step 122, a determination is made as to whether the source of the decoder terminal is requested by the software object (if the software object has requested the use of the resource through the OS). If step 122 determines that a valid resource of the decoder terminal has not been requested, no further action is taken. However, if step 122 determines that a valid resource of the decoder terminal has been requested, the process continues to pasol24, in which the OS invokes the operator associated with the resource of the requested decoder terminal. Continuing to step 126, the associated operator (only at the first use of the resource) invokes a "Second Conditional Access routine" (which may be part of the BIOS or operating system) to determine if the requesting software object is allowed to use this resource. More specifically, the operator routine calls the second access control routine, which, in conjunction with the insurance processor, determines whether the software object can use the requested resource (for example, it determines whether it is authorized for said use). ). The rights to authorize the use of the resource are also stored in the insurance memory. Specifically, in step 128, it is determined whether the EMM provided the permission to use the requested resource. If the EMM did not provide such permission, the process does not allow the use of the requested resource (step 130) (for example, the control returns to the operator and then to the OS with a negative result, indicating that the requested resource use is not allowed) . However, if the EMM granted the permission, the use of the requested decoder resource is allowed in step 132. In addition, in the case where the permits are established as Impulse insurers (requiring an explicit request from the user for the authorization to take effect), the routine grants the authorization and registers the Impulse request within the insurance processor (for possible subsequent billing purposes, through a report return mechanism to the CA or the DAC). Still in a further aspect of a preferred embodiment of the present invention, the operator associated with the requested resource, can invoke the second CA routine only at the first use of the resource by the software object, wherein the subsequent invocations of the second routine of conditional access are optional. Finally, those skilled in the art will appreciate that several methods can be implemented in order to detect any attempt to circumvent the processes described above. These methods may include periodic reviews of the memory of the software object, fingerprint (which may include memory size, revision of sum, etc.) including the BIOS of the decoder terminal core, the System Operational, etc., again, the previously calculated and protected values of each one. Specifically, for example, the secure processor of the decoder terminals in conjunction with the user's processor can perform a checksum of memory on certain critical software components. This can be done, provided that the user processor and the insurance processor have sufficient idle time to perform this function in order to minimize the adverse effects of operation on the other functions. It can also be invoked, at the request of the operator, by means of a received command message (from the MSO controller), in case the MSO wants to verify the integrity of the software as part of a fault location test or monitoring process . The insurance processor has the cryptographic checksum of the software component that is going to be reviewed. The user's processor, under the control of the operating system, passes the memory segments that comprise this object to the insurance processor. If the insurance processor determines that the revision has failed, it can incorporate the condition into an encrypted format, which is incorporated into a message that is sent to the MSO driver. If the reliability of the user's processor for this purpose can be minimized to ensure that these operations can not be intercepted. In addition, in the case of intrusion attempts or transmission errors (in any case, a "deviation") is detected, additional indications can be provided, for example, by pointing the unique address of the decoder terminal to the MSO (main end for close all or some of the services to the subscriber, notifying the Local or National Access Control Center of the event, the time, the unique address of the decoder terminal, the geographic location, etc.). Although various embodiments have been specifically illustrated and described in the present description, it will be appreciated that various modifications and variations of the present invention are covered by the foregoing teachings, and within the scope of the appended claims, without departing from the intended spirit and scope. of the present invention.

Claims (31)

  1. NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following is claimed as property: CLAIMS 1. A method for providing authorization and access control of a software object that resides in terminals of digital decoder, comprising the steps of: creating a fingerprint for each software object; association of each fingerprint with a service insurer; coding of each association made in said association step; creation of an association table containing the information generated in said coding step; downloading the association table to the digital decoder terminal; transmission of a message, providing an indication of which software the encoder terminal can use, to the digital decoder terminal; and providing a routine system in the digital decoder terminal, which is invoked whenever the software object has been downloaded or is going to be used, where the system routines use an association table to determine whether the object of software that is about to be invoked has been authorized for the decoder terminal. The method in accordance with the claim 1, where the software object has been verified and validated additionally, before the mentioned steps. 3. The method according to claim 1, which further comprises the steps of: registering a lifetime of the software object; and start with the first use, review of the lifetime of the software object for its expiration. 4. The method of compliance with the claim 3, wherein if the determination is made in said revision step that the lifetime of the software object has expired, it additionally comprises the step of disabling the software object. 5. The method according to claim 1, wherein if a plurality of software objects are associated with a service, further comprises the step of: creating a fingerprint for the plurality of software objects as a group. 6. The method according to claim 1, wherein the transmitted message further indicates which decoder terminal resource is authorized to use the software object. 7. The method of compliance with the claim 6, where an authorization impulse service insurer can be assigned to facilitate the immediate authorization of a resource. 8. The method of compliance with the claim 7, wherein the insurer of the impulse authorization service has a duration of time associated therewith. The method according to claim 1, wherein further, the message transmitted in said transmission step, provides the indication by adjusting the corresponding service insurers. 10, The method according to claim 1, wherein additionally, if the service insurer has not been authorized, the object of the software is not executed. The method according to claim 1, wherein further, if the service insurer has been authorized, revisions of the system routine determine whether the object of the software to be used passes a corresponding fingerprint review. 12. The method in accordance with the claim 11, wherein if the software object to be used passes the corresponding fingerprint review, it additionally comprises the step of: determining if the use of the resource of the decoder terminal has been requested. 13. The method according to the claim 12, wherein if a determination has been made in said determination step that the use of the resource of the decoder terminal has been requested, it further comprises the step of: providing a second system routine in the digital decoder terminal. 14. The method according to claim 12, wherein if a determination has been made in said determination step that the use of a resource of the decoder terminal has been requested, it additionally comprises the step of: determining if it is the first time the use of the resource has been requested of the decoder terminal by the software object, wherein, if it is the first time that the use of the resource has been requested, a second system routine is provided in the digital decoder terminal. 15. The method according to claim 13, wherein the second system routine uses transmitted messages to determine if the software object can use the resource of the requested decoder terminal. 16. The method according to claim 11, wherein additionally, if the object of the software to be used does not have the corresponding fingerprint, the software object is not exempted. The method according to claim 1, wherein the fingerprint of the software object residing in the terminal of the decoder is periodically compared with a reference value and an indication of a deviation is provided. 18. A method for providing authorization and access control of applications running on the digital decoder terminals, comprising the steps of: associating each application with a service insurer; code each association made in said association step; create an association table that contains the information generated in said coding step; download the association table to the digital decoder terminal; and providing a system routine in the digital decoder terminal that is invoked whenever an application has been invoked, wherein the system routine uses the application association or the association table to determine whether an invoked application is associated with a service insurer; and where, if the invoked application is not associated with a service insurer, the application is not used. The method according to claim 18, wherein, in addition, if an invoked application is associated with a service insurer, the system routine further determines whether the insurer corresponding to the service / application has been authorized. The method according to claim 18, wherein, when control of the resource of the decoder terminal is diverted for a single application in all the decoders, it additionally comprises the step of: providing an indication of the control of the resource of the decoder. decoder terminal in the coded associations, wherein a second system routine uses the association table to determine if the software object can use the resource of the requested decoder terminal. 21. The method according to claim 18, wherein the indications of the resource control of the decoder terminal are transported to each encoder individually. 22. The method according to claim 18, wherein the software memory size of the critical software components of the digital decoder terminal is periodically compared to a reference value and an indication of a deviation is provided. 23. The method according to claim 18, wherein the software size of an operating system of the digital decoder terminal is periodically compared to a reference value and an indication of a deviation is provided. The method according to claim 18, wherein the memory size of the software object of the application code image in the digital decoder terminal is periodically compared to a reference value and an indication of a deviation. The method according to claim 18, wherein the checksum of the critical software components of the digital decoder terminal is periodically compared with a reference value and an indication of a deviation is provided. 26. The method according to claim 18, wherein the checksum of the operating system of the digital decoder terminal is periodically compared with a reference value and an indication of a deviation is provided. The method according to claim 18, wherein the check sum of the software object in the digital decoder terminal is periodically compared to a reference value and an indication of a deviation is provided. 28. A system for providing control of authorization and access of a software object that resides in the digital decoder terminals, which comprises: a cable system multiple operator site comprising: means to create a fingerprint for each object of the software; means for assigning each fingerprint to a service insurer; means for coding each association made in said association step; means to create an association / message table that contains the information generated in said coding step; means for downloading the association table to the digital decoder terminal; means for transmitting a message, providing an indication of which software the decoder terminal can use, to the digital decoder terminal; and a digital decoder terminal comprising: a system routine that is invoked whenever the software object has been downloaded or is going to be used, wherein, the system routine uses the association / message table to determine whether the object of the software that is to be invoked has been authorized for the decoder terminal. 29. The system in accordance with the claim 28, wherein said means for creating a fingerprint, comprises an independent software apparatus / signature verification of the HW object (OASD). 30. The system in accordance with the claim 29, wherein the OASD comprises said means for assigning each fingerprint to a service insurer. 31. A digital decoder terminal operating in conjunction with a cable system multiple operator system to provide authorization and access control of a software object residing in the digital decoder terminal, the decoder terminal comprising: a routine of system that is invoked whenever the software object has been downloaded or is going to be used, where, the system routine uses an association / message table, created in the MSO and downloaded to the decoder terminal, to determine if the object of the software to be invoked has been authorized for the decoder terminal, and where in addition, the association / message table comprises a coded fingerprint for the association of the service insurer corresponding to the software object. SUMMARY A method for providing verification control, authorization and access of a software object that resides in digital decoder terminals that creates a fingerprint ("signature") for each software object, associates each fingerprint with a service insurer , encode each association and create an association table that contains the information, and download the association table to the digital decoder terminal. In addition, the method uses a rights management message, sent to each decoder terminal indicating which software objects the decoder terminal can use, and provides a system routine in the digital decoder terminal, which is invoked whenever it is going to be used a software object. The rights management message contains the access rights determined for a particular decoder terminal, which must match the access requirements of the software objects for the software object to be used. The rights management message may also contain the control access rights of the decoder terminal resource that may be used by a particular software object. When the software object requires the use of a decoder resource, a second conditional access routine can be invoked to determine the authorization rights to use the resource. Measures to protect said means are also described. As such, the method provides multiple cable system operators (MSOs), with additional capabilities to maintain secure control of the features and applications that operate on their networks and within their associated decoder terminals.
MXPA/A/2001/008592A 1999-02-24 2001-08-24 Authorization and access control of software object residing in set-top terminals MXPA01008592A (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09257274 1999-02-24

Publications (1)

Publication Number Publication Date
MXPA01008592A true MXPA01008592A (en) 2002-05-09

Family

ID=

Similar Documents

Publication Publication Date Title
US6256393B1 (en) Authorization and access control of software object residing in set-top terminals
US6711683B1 (en) Compresses video decompression system with encryption of compressed data stored in video buffer
US6775778B1 (en) Secure computing device having boot read only memory verification of program code
US6266754B1 (en) Secure computing device including operating system stored in non-relocatable page of memory
US8108680B2 (en) Preventing unauthorized poaching of set top box assets
US8904424B2 (en) Object and resource security system
US7376625B2 (en) System and method for activating individualized software modules in a digital broadcast environment
US20040015958A1 (en) Method and system for conditional installation and execution of services in a secure computing environment
EP0961193A2 (en) Secure computing device
US20070103997A1 (en) System for restricting data access
US7765600B2 (en) Methods and apparatuses for authorizing features of a computer program for use with a product
EP1228634B1 (en) Intrusion detection for object security
US6757829B1 (en) Program debugging system for secure computing device having secure and non-secure modes
EP1662693B1 (en) Digital literary work protection system and digital literary work protection method
US20020138757A1 (en) Method for securely distributing software components on a computer network
US20030018445A1 (en) Detection of unauthorized applications, objects, or configurations in a local device of a cable system
EP1221077B1 (en) Detection of suspect software objects and signatures after failed authentication
MXPA01008592A (en) Authorization and access control of software object residing in set-top terminals
KR100679498B1 (en) Entitlements of objects and resources
KR100947313B1 (en) Method and apparatus for authenticating based on downloadable conditional access system